Protect unsupported Lodash dependencies without a disruptive replacement project
Lodash’s maintainers only ship fixes for the current 4.x line. Endless Lifecycle Support backports security fixes to the 1.x–4.x releases you can’t upgrade from, with no code changes required.
Jump to:
Talk to Us
Ask about coverage, SLAs, pricing, or anything else.
Covered Lodash Versions
Unsupported since
September 2013
Covered by ELS
Unsupported since
January 2015
Covered by ELS
Unsupported since
January 2016
Covered by ELS
Unsupported since
February 2015
Covered by ELS
Unsupported since
February 2018
Covered by ELS
Unsupported since
April 2018
Covered by ELS
Unsupported since
July 2020
Covered by ELS
Unsupported since
August 2020
Covered by ELS
Unsupported since
January 21, 2026
Covered by ELS
⚠️ EOL Date
Not Published
by Vendor
Covered by ELS
Unsupported
starting
February 2016
Covered by ELS
*EOL dates are based on Lodash’s version support policy
What You Get with ELS
Security Fixes for the Lodash That Upstream Abandoned
From prototype pollution to ReDoS, injection flaws, and more, TuxCare monitors new Lodash CVEs and delivers tested fixes for nine covered releases, even when replacing the dependency isn't practical.
On day 1
Previously delivered Lodash patches are available the moment your project connects to the ELS registry.
Patch Lodash Without Reworking Your Code
ELS replaces your existing Lodash package with a TuxCare-maintained equivalent, preserving the version and behavior your application already relies on.
ELS delivers patched packages through the TuxCare npm registry and covers both direct and transitive dependencies. It fits your existing npm workflow, from package.json overrides to Docker and CI/CD builds.
Support That Holds Up to Review
SLA-Backed Patch Delivery
TuxCare’s patch delivery SLA helps your organization meet vulnerability remediation expectations under frameworks and regulations such as SOC 2, NIS2, PCI DSS, HIPAA, DORA, and the CRA.
Enterprise Support Guarantees
ELS is built for enterprise use, with commercial support terms and contractual protections designed for organizations that need more than community best-effort maintenance.
Add patched Lodash packages through npm with no application code changes required
Configure the TuxCare npm registry, update your package references, and reinstall your project dependencies.
A head start on Lodash security
Begin with existing fixes for your covered version and stay protected as new disclosures land.
Ask a Lodash CVE patching expert
Discuss which covered releases appear in your dependency tree and how to replace them with maintained packages.
How Does It Work?
We onboard new projects and enable 24/7 automated CVE tracking – monitoring the NVD, vendor, and GitHub security advisories, and other sources.
Once CVEs are detected, we backport upstream fixes using algorithmic and AI-assisted automation, with expert validation to ensure accuracy.
Patches are compiled in a binary format, extensively tested (for integrity, functionality, and regression), signed, and deployed to ELS repositories.
Your package managers, build tools, or orchestrators check for updates, then automatically pull and install them.
How Teams Use ELS
Silence the
scanner
⚠️ The bind:
Multiple applications depend on different Lodash releases, including older 3.x and 4.17.x versions that can't all be upgraded safely at once.
🔄 The turn:
ELS patches each covered release independently, so teams remediate vulnerabilities while preserving the exact version each application expects.
Close an open audit finding
⚠️ The bind:
Internal audit, SOC 2, and customer questionnaires all flag unmaintained Lodash, and there's no remediation date to give, because the project is done shipping.
🔄 The turn:
ELS delivers vendor-backed packages under a contractual SLA, with a documented remediation path. Findings close, and questionnaires point to coverage aligned with PCI DSS, HIPAA, SOC 2, DORA, NIS2, and CRA.
Modernize on your terms, not the CVE clock
⚠️ The bind:
Removing Lodash touches shared utilities, older front ends, and thousands of call sites. That’s more regression work than any roadmap can absorb.
🔄 The turn:
ELS keeps covered releases patched while teams inventory usage, test alternatives, and modernize on a schedule that protects stability – or don't, and stay covered.
Why TuxCare?
420,000+
Patches Delivered
From the Team That Extends Open-Source Lifecycles
TuxCare keeps essential components protected long after upstream support ends, from the Linux kernel to npm packages like Lodash. One partner, whole-stack coverage.
14,000+
Vulnerabilities Fixed
Founding platinum sponsor of the AlmaLinux OS Foundation and member of the Open Source Security Foundation (OpenSSF).
TuxCare invests in the open-source ecosystem it secures, from Lodash and npm packages to Linux, and beyond.
Learn more →
70,000+
Packages Curated
2,700+
Enterprise Clients
Related Insights
.NET 6 End of Life: What It Means for Your Business in 2026
Key Takeaways .NET 7 is no longer supported — migrating to a supported version...
.NET 8 End of Life: Key Dates, Risks & Next Steps Now
Key Takeaways .NET 6 reached End of Life on November 12, 2024, leaving systems...
Critical .NET Security Alert: CVE-2025-24070 Impacts .NET 6 Despite...
Our security research team has identified that the recently disclosed vulnerability...
Lodash isn't getting patched. Your apps still can be.
Get ongoing CVE fixes for covered Lodash 1.x–4.x packages through the npm workflow you already use.
Ask Us a Question
Frequently Asked Questions
No. Lodash has not shipped a release since version 4.17.21 in 2021, and no Lodash 5 has been announced. The library remains one of the most-downloaded npm packages, but new vulnerabilities are no longer fixed upstream. TuxCare's Endless Lifecycle Support (ELS) provides continued CVE patches for nine covered Lodash releases across versions 1.x through 4.x.
Replace your Lodash package with a security-patched, drop-in equivalent instead of refactoring it out. TuxCare ELS delivers maintained versions of covered Lodash releases through its npm registry: you add two lines to .npmrc, update package.json (manually or with the automated TuxCare Patcher), and run npm install. No utility calls, imports, or application logic change.
ELS covers nine Lodash releases: 1.3.1, 2.4.2, 3.2.0, 3.10.1, 4.5.0, 4.17.15, 4.17.19, 4.17.21, and 4.18.1. Coverage spans major versions 1 through 4, including the widely deployed 4.17.x line. If your application pins a different release, contact TuxCare to discuss coverage options.
Yes. Prototype pollution is the most common class of Lodash CVE, and ELS delivers tested fixes for known vulnerabilities affecting covered releases. Plus, new patches as future CVEs are disclosed. On day one, your project inherits all fixes already shipped for your version.
Yes. ELS uses npm overrides in package.json to redirect every instance of a covered Lodash version (including copies pulled in by packages you don't control) to the TuxCare-maintained equivalent. The TuxCare Patcher can detect covered versions and write these overrides automatically.
No. ELS packages are drop-in replacements for covered releases, installed through your existing npm workflow. Setup is a .npmrc registry entry and a package.json dependency swap, then npm install. You keep the same Lodash API, behavior, and version your application already expects.
Yes. ELS packages resolve through npm from the TuxCare registry, so they work anywhere npm does. This includes docker builds, CI/CD pipelines, and existing deployment workflows. The registry token is read automatically from your project's .npmrc.
ELS is designed to support vulnerability-remediation requirements under frameworks including SOC 2, PCI DSS, HIPAA, NIS2, DORA, and the CRA. Patches are delivered under a contractual SLA from a named vendor, giving auditors a documented remediation path for an otherwise unmaintained dependency.
It depends on your timeline and risk tolerance. ELS makes it a choice rather than an emergency. Removing Lodash means touching shared utilities and potentially thousands of call sites, while ELS keeps covered releases patched immediately through npm. Many teams use ELS to stay secure and compliant now, then modernize deliberately or not at all.