Inside Lodash’s Security Reset and Maintenance Reboot

For more than a decade, Lodash has been one of the most widely deployed libraries in the JavaScript ecosystem. Its utilities are deeply embedded in frameworks, build systems, and production applications across the web.

Like many foundational dependencies, Lodash evolved into critical infrastructure long before the ecosystem had strong models for funding, governance, or long-term security operations. Over time, that gap between usage and institutional support made it harder to ship releases, respond to security reports, and maintain the project at the level its footprint demands.

Lodash maintainers are writing a new chapter in the project's history with the release of 4.17.23, alongside the publication of CVE-2025-134655. While the patch itself addresses a moderate-severity prototype pollution issue affecting .unset and .omit, the bigger story is that Lodash is being actively maintained again.

This is the first Lodash security release in several years, and it's part of a deliberate effort to rebuild the project’s operational and governance foundations before attempting to ship fixes.

That work has been driven by a newly expanded Technical Steering Committee, backed by public funding from OpenJS and the Sovereign Tech Agency, and reflects a renewed focus on treating Lodash as long-term infrastructure rather than a dormant library that occasionally needs attention.

Rebuilding Security From First Principles#

One of the earliest challenges the new TSC faced was a backlog of historical security reports that had accumulated during years without a shared vulnerability process. Rather than treating the backlog as a cleanup task, the committee stepped back and focused on formalizing processes that had previously been handled informally by a very small group of maintainers.

Ulises Gascón, a member of the Lodash TSC, said the group deliberately avoided rushing to close issues.

“The first decision was to not treat it as a one-off cleanup exercise," he said. "We assumed most of the backlog existed because the project lacked a shared security process, not because the reports were low quality.”

With that foundation in place, the committee was able to revisit older reports with a level of consistency that had not been possible before, bringing multiple reviewers into decisions that had previously fallen to individual maintainers.

“So instead of closing things quickly, we first defined a threat model and an incident response workflow,” Gascón said. “That gave us a consistent way to ask: Is this actually exploitable in Lodash’s real usage model? What class of risk is this? Who decides?”

Only after those questions had clear answers could the group begin triaging older reports. According to Gascón, having common criteria and multiple reviewers changed the dynamic entirely.

“Many of them became much easier to evaluate once we had common criteria and multiple reviewers instead of a single maintainer making judgment calls in isolation.”

“Security work is emotionally expensive and invisible.”#

That process work quickly surfaced another problem. Over time, the entropy of long-term load combined with limited resources had made it difficult to maintain the level of reliability required for credible security work without first stabilizing the basics.

“The most painful part was that a lot of critical infrastructure had silently degraded,” Gascón said. “Tests did not reliably run, browser coverage was unclear, and some reports could not even be reproduced anymore.”

Rebuilding the test and release pipeline clarified what Lodash could realistically support and what guarantees it could make to users.

“Rebuilding CI forced us to make many things explicit that had previously lived only in people’s heads: supported environments, security boundaries, release criteria.

“It was uncomfortable because it exposed how fragile the project actually was operationally, but that was also exactly what made it necessary. You cannot have credible security work if your test and release pipeline is not trustworthy.”

This infrastructure reset enabled Lodash to ship a coordinated fix for CVE-2025-134655, something that had not been feasible in years.

Shared Ownership as a Security Control

Beyond tooling, the Lodash reboot introduced structural changes aimed at reducing systemic risk. Shared ownership for security decisions was a deliberate design choice, not just a governance formality.

“In practice, it eliminates three major risks,” Gascón said. “First, the bus factor. No single person becomes a critical dependency for vulnerability handling. Second, cognitive bias. Security decisions are reviewed by people with different assumptions and threat perspectives. Third, burnout. Security work is emotionally expensive and invisible, and sharing it makes it sustainable.

“From a user’s perspective, the most important effect is predictability. There is now a stable process that will exist even if individual maintainers change.”

Lodash Is Critical Infrastructure#

Lodash’s situation is not an isolated case in open source. Widely used dependencies often reach infrastructure-level importance faster than the ecosystem develops reliable ways to fund, govern, and secure them.

High-profile incidents like Heartbleed and Log4Shell made the ecosystem acutely aware of this lack of support for a brief, vanishing moment, but translating awareness into durable support has remained a persistent challenge.

Despite years of public discussion about maintainer burnout and supply chain risk, many projects continue to rely on informal processes and unpaid labor to support software embedded across millions of systems.

In Lodash’s case, the newly formed and funded TSC represents some of the first cracks in the ice in how the JavaScript ecosystem treats foundational dependencies.

“I would say it is still a fragile and incomplete shift,” Gascón said when asked whether Lodash reflects a larger trend. “What is changing is that institutions are starting to recognize that some projects are infrastructure, not products. They need governance, funding, and long-term stewardship, not just maintainers working in their spare time.”

While the OpenJS Foundation hosts and benefits many widely used JavaScript projects, the Lodash funding and governance reboot is one of the earliest instances in the ecosystem where public funding has been explicitly tied to long-term security processes and maintenance infrastructure for a single, widely depended-upon library.

“The code itself was never the main problem," Gascón said. "The problem was that something used by millions of systems had no organizational backbone.”

Socket engineer Jordan Harband, who also serves as a Lodash TSC member, echoed that concern.

“Some wanted lodash to be ‘shut down’ or sunset, but those of us in OpenJS were painfully aware that you can’t just ‘disappear’ a third party dependency,” Harband said. “We felt that the only way to maximize the chances of lodash users not being stranded on an unsupported, insecure project was to ensure lodash continues as a sustainable effort moving forward.”

A Smaller, More Sustainable Future#

Looking ahead, the Lodash roadmap prioritizes stability and sustainability over expansion. The goal is not to make Lodash more ambitious, but more maintainable.

Near-term work centers on simplifying Lodash’s internals by leaning more on native JavaScript, while preserving the APIs developers rely on. As modern engines absorb functionality Lodash once had to provide itself, the library can stay efficient without introducing breaking changes.

Longer-term plans include moving past legacy runtime support and reducing fragmentation across Lodash’s many variants, focusing maintenance effort on a smaller, more coherent core.

Harband described plans for a new major release paired with significant consolidation.

“We plan to have a new major release, combined with an aggressive pruning of APIs that have modern solutions (and migration tools, such as codemods, to help with that), so that lodash is smaller and easier to maintain, and fewer people will need lodash in their applications.”

For Gascón, success looks less like visible milestones and more like quiet reliability. “Success for me is mostly invisible. Fewer security surprises, predictable releases, more contributors able to review and merge changes, and no single person feeling indispensable.”

That philosophy also shapes how the team is thinking about deprecations and consolidation.

“Supporting obsolete runtimes is not neutral. It actively limits your ability to improve security and maintainability,” Gascón said. “Consolidation is controversial because it feels like loss, but fragmentation also has a cost.”

Socket engineer John-David Dalton, Lodash’s creator, emphasized that this approach aims to balance continuity with necessary change.

“The help around the project tech-debt (build system, CI, website, testing, publishing), and help around process (security review, cve creation and management) is very much welcomed,” Dalton said. “Having folks there to answer questions and double check and review has been critical to achieve movement in the project.”

Dalton also pushed back on the idea of sunsetting Lodash entirely, instead describing an approach focused on ongoing maintenance and gradual reduction of surface area.

“I think we’re on the right balance which is update so we can fix bugs and create releases, plan for deprecation of APIs/methods without turning off the lights completely. Smaller surface area as we progress is a win, having processes and mechanisms (that work) for releases is a win.”

Lodash 4.17.23 is not a return to rapid feature development. Instead, the project has re-entered a state where it can reliably respond to vulnerabilities, ship coordinated releases, and communicate clearly with users.

For a dependency that sits so deeply in the JavaScript supply chain, that shift matters far beyond a single CVE. It reflects a growing recognition that sustainability, governance, and security operations are not optional extras for widely used open source projects. They are the work.