Is Lodash Safe? A 2026 Security Guide

Lodash is one of the most depended-upon libraries in the entire JavaScript ecosystem. It ships a few hundred small, well-tested utility functions for working with arrays, objects, strings, and collections, and it is pulled into everything from CLI tools to front-end bundles to server frameworks. On npm it sees tens of millions of weekly downloads and sits as a direct or transitive dependency of hundreds of thousands of packages. That ubiquity is exactly why "is lodash safe?" is a question worth answering carefully — when a bug lands in lodash, it lands almost everywhere at once.

The notable historical CVEs

Lodash's security history is dominated by one class of bug — prototype pollution — plus a couple of notable outliers. These are all real, published advisories:

• CVE-2018-3721 — prototype pollution via _.defaultsDeep, fixed in 4.17.5.
• CVE-2018-16487 — a more complete prototype pollution fix covering _.merge, _.mergeWith, and _.defaultsDeep, fixed in 4.17.11.
• CVE-2019-10744 — a critical (CVSS 9.1) prototype pollution in _.defaultsDeep that allowed adding or modifying properties of Object.prototype, fixed in 4.17.12.
• CVE-2020-8203 — prototype pollution via _.zipObjectDeep (and the _.set/_.setWith family), addressed across 4.17.16 through 4.17.19.
• CVE-2020-28500 — a regular-expression denial of service (ReDoS) in _.trim, _.trimEnd, and _.toNumber, fixed in 4.17.21.
• CVE-2021-23337 — command injection in _.template when the template or its options are attacker-influenced, also fixed in 4.17.21.

The through-line: the deep object-manipulation helpers repeatedly allowed a crafted key such as __proto__ or constructor.prototype to walk up the prototype chain and mutate shared objects. That is prototype pollution, and it can escalate from a subtle logic bug to authentication bypass or remote code execution depending on what your application does with the polluted object afterward.

Common misuse and risks

The dangerous pattern is almost always the same: passing untrusted input into a deep-merge or deep-set helper. Code like _.merge({}, req.body) or _.set(config, userSuppliedPath, value) on an unpatched version hands an attacker a direct route into Object.prototype. Even on a patched version, deep-merging untrusted data is a smell worth reviewing.

The second common trap is _.template. Developers reach for it as a lightweight templating engine, but if either the template string or the compile options come from user input, CVE-2021-23337 shows it can be turned into arbitrary code execution. Treat _.template as a code-generation primitive, not an HTML renderer.

Finally, there is the silent-transitive problem. Many teams do not use lodash directly at all — it arrives three layers deep through another dependency, pinned to an ancient version in a stale lockfile. You cannot fix what you do not know you are shipping, and "we don't use lodash" is frequently wrong.

How to use lodash safely

Start with the version floor: run lodash 4.17.21 (the current 4.x release), which carries fixes for every CVE listed above. If a transitive dependency drags in an older lodash, override it in your lockfile so the resolved version is patched.

Beyond the version:

• Never pass raw request bodies into _.merge, _.mergeWith, _.defaultsDeep, _.set, _.setWith, or _.zipObjectDeep. Validate and allowlist keys first, or deserialize into a schema.
• Avoid _.template for any input a user can influence. Use a purpose-built, auto-escaping template engine instead.
• As defense-in-depth against prototype pollution generally, prefer Object.create(null) or Map for dictionaries built from external data, and consider freezing Object.prototype in server processes where you control the whole runtime.
• Import only what you use (lodash/merge or the lodash-es per-method entry points) to shrink your surface and let bundlers tree-shake — smaller surface, easier auditing.

How to monitor lodash with SCA and reachability

Lodash is the textbook case for why reachability matters. A pure version-based scanner will flag lodash CVEs in nearly every JavaScript repository you own, because lodash is nearly everywhere — and most of those findings are noise, because your code never calls the vulnerable function with untrusted data. Reachability-aware software composition analysis answers the question that actually decides urgency: does a code path in your application reach _.merge or _.template with input an attacker controls?

Safeguard's software composition analysis resolves your full lockfile — including the transitive lodash you did not choose — and layers call-path reachability on top, so the handful of genuinely exploitable findings are separated from the long tail that is present but unreachable. When a patched version exists, autonomous auto-fix opens a pull request that bumps lodash (or pins the transitive override), re-runs your tests, and lets you merge in minutes instead of chasing the dependency graph by hand. Developers keep the same analysis in their local loop and in CI through the Safeguard CLI.

Bring continuous, prioritized dependency analysis to your JavaScript services — get started free or read the documentation.

Frequently Asked Questions

Is lodash safe to use in 2026?

Yes, provided you run 4.17.21 and do not feed untrusted input into its deep-merge or templating helpers. Lodash's known CVEs are all patched in the current release; the residual risk comes from misuse and from stale transitive copies, not from the maintained version itself.

Which lodash version should I be on?

Pin lodash to 4.17.21, the latest 4.x release, which includes fixes for the prototype pollution, ReDoS, and command-injection advisories. If a dependency pulls in an older lodash, add a lockfile override so the resolved version is 4.17.21 or later.

What is prototype pollution and why does lodash keep getting hit by it?

Prototype pollution is an attack where a crafted key such as __proto__ mutates Object.prototype, changing the behavior of every object in the process. Lodash's deep object helpers historically walked those keys, which is why several CVEs cluster around merge, defaultsDeep, and zipObjectDeep. Patched versions block the dangerous keys, but validating input remains the durable defense.

Do I still need to worry about lodash if I never imported it?

Very possibly, yes. Lodash is one of the most common transitive dependencies in the ecosystem, so it may be in your build even if it is absent from your package.json. A software composition analysis tool that reads the full lockfile will show you every resolved copy and its version.

How do I know if a lodash CVE actually affects my app?

Use reachability analysis. It traces whether your code reaches the vulnerable function with attacker-influenced input, which turns a blanket "lodash is vulnerable" alert into a specific, prioritized finding you can act on — or safely defer.