Lodash remains a quiet but essential part of the JavaScript ecosystem that is deeply embedded in frameworks, build systems, and production applications across the web. With the release of Lodash 4.17.22 and the publication of CVE-2025-13466, the project is making visible progress in strengthening its security posture.

Over the past two months, an expanded Lodash Technical Committee reviewed and addressed the security backlog, filed a CVE through the OpenJS CVE Numbering Authority (CNA), and put in place a modern, documented vulnerability-reporting workflow. 

These efforts build on the momentum outlined in our earlier update, Sovereign Tech Agency Invests in Lodash’s Next Chapter in Open Source, and reflect a coordinated, renewed approach to maintaining Lodash security even after years of limited activity.

A practical fix, backed by real process

The 4.17.22 release includes a patch for a prototype pollution vulnerability affecting .unset and .omit in versions 4.0.0 through 4.17.21. Under certain conditions, an attacker could pass crafted paths that result in deleting properties from global prototypes. This issue allows deletion of properties but does not allow overwriting their behavior. Based on scope and impact, it was rated as moderate severity.

While the technical change itself is relatively contained, the significance is in the process behind it. This is the first Lodash security release in several years, and it reflects a structural change in how the project approaches vulnerabilities. 

The backlog of historical reports was not simply closed or deferred. Instead, each report was reviewed, triaged, and evaluated against a newly documented set of procedures, leading to a concrete fix, a coordinated advisory, and a public release.

Why this release marks a turning point 

This release did not happen in isolation. Over the past weeks, the Lodash team, with support from the broader OpenJS ecosystem, focused on rebuilding the project’s operational foundation before attempting to ship fixes. That work centered on three pillars: governance, security operations, and infrastructure.

New Governance

A formal Technical Steering Committee was established alongside a dedicated security triage group. This gave the project both technical direction and a clear accountability structure for security decisions and escalations. Instead of security reports living in personal inboxes or ad hoc channels, they now flow through an agreed process with shared ownership and documented outcomes.

Enhanced Security Operations

The project introduced a complete incident response plan and a formal threat model. GitHub Security Advisories were properly enabled and integrated into the workflow, bringing Lodash into alignment with how other OpenJS projects handle vulnerability intake and disclosure. The team also adopted tooling to reduce drift and blind spots, including CodeQL for static analysis, automated dependency updates via Renovate, dependency review in pull requests, and continuous monitoring through the OpenSSF Scorecard.

Refreshed Infrastructure

The continuous integration system was effectively rebuilt. Long-standing issues that prevented reliable test execution were resolved, Node.js version coverage was restored and extended, and support for newer runtimes like Bun was added. A dedicated documentation pipeline now validates changes independently, and browser testing was reintroduced using a modern Playwright-based setup with a focused compatibility matrix. Legacy and unused configuration was removed, and supported runtimes and browsers are now clearly documented for users and contributors.

None of this work is glamorous. But without it, publishing a credible security fix would not have been possible.

What this means for Lodash as a project

This CVE release marks a turning point. It shows that Lodash is no longer in maintenance stasis. The project has transitioned back into a state where it can responsibly respond to security issues, publish updates, and communicate clearly with its users.

Equally important, it reflects a broader shift in how critical JavaScript infrastructure is being supported. Lodash’s recent governance reboot and security investments build directly on the earlier work enabled through OpenJS and external funding partners. That effort was not just about adding features or modernizing syntax. It was about making sure a widely used dependency could be trusted to handle slow, careful, unglamorous maintenance work again.

This matters because Lodash is not just another library. It is part of the web’s supply chain. When a project of this scale resumes regular, structured maintenance, it reduces risk far beyond its own repository.

The next phase: stability first, features later

Looking ahead, the project’s priorities are intentionally conservative. Lodash does not need a flood of new features. Its users need stability, predictability, and a clear long-term direction.

A major focus is rewriting internal implementations to use native JavaScript, while keeping public interfaces unchanged. Modern engines like V8 now optimize many utilities Lodash once polyfilled, letting the library stay fast and relevant without disruptive changes.

The next major version will likely drop support for older runtimes, moving the codebase forward with modern syntax in a measured, predictable way. Another priority is trimming the ecosystem of Lodash variants like deprecated forks and micro-packages to be streamlined into a single, better-maintained core.

Rebuilding Trust Through Steady, Repeatable Work

Security improvements are often invisible when done well. What users see is a version number change and a short changelog entry. What they do not see are the months of governance changes, process writing, CI repair, tool integration, and backlog triage behind it.

Lodash 4.17.22 is not just a patch release. It is evidence that the project has re-entered a phase of active, structured stewardship. Our goal now is not novelty, but trust. Reliable processes, clear communication, and steady reduction of technical and organizational risk.

This is what sustainable maintenance looks like for critical JavaScript infrastructure. And this release is one small, concrete step in that direction.