The lodash npm package is safe to use if you are on 4.17.21 or later, but older versions carry real prototype pollution vulnerabilities that a lot of projects still drag in transitively. Lodash is one of the most-depended-upon libraries in the entire JavaScript ecosystem, which cuts both ways: it is battle-tested, and a flaw in it reaches an enormous number of applications. The specific risk that made npm lodash a recurring audit finding is prototype pollution, and the fix is simply staying current.
Because lodash shows up as a transitive dependency of countless other packages, you can be running a vulnerable copy without ever typing npm install lodash. That is the part worth understanding.
What Prototype Pollution Actually Is
JavaScript objects inherit from a shared prototype. Prototype pollution is a class of bug where an attacker manipulates a property like __proto__ to inject or overwrite properties on Object.prototype. Because nearly every object inherits from it, a polluted prototype can change behavior across the whole application: bypassing checks, altering configuration, or in some setups enabling more serious attacks like denial of service or code execution downstream.
Utility libraries that deep-merge or set nested properties from untrusted input are natural places for this bug, which is exactly where lodash was hit.
The Lodash Prototype Pollution CVEs
Two prototype pollution advisories drove the lodash upgrade cycle:
- CVE-2019-10744 affected lodash before 4.17.12. The
defaultsDeepfunction could be tricked into polluting the object prototype. This was fixed in 4.17.12. - CVE-2020-8203 affected versions prior to 4.17.19, with the fix landing in 4.17.20. It involved prototype pollution through functions including
zipObjectDeep.
Both, along with the other known lodash advisories, are resolved in 4.17.21, which is the version to standardize on. There is no reason to run anything older, and 4.17.21 has been the recommended safe baseline for years.
Why You Might Be Vulnerable Without Knowing
Here is the trap. You upgrade your direct lodash dependency to 4.17.21 and assume you are clean. But another package in your tree declares a dependency on an older lodash range, and your package manager resolves a second, vulnerable copy deep in node_modules.
Check what actually resolved rather than what you think you installed:
npm ls lodash
This prints every path that pulls in lodash and the version each resolved to. If you see a 4.16.x or an early 4.17.x hanging off some transitive dependency, that is your exposure, regardless of what your own package.json says.
Forcing a Safe Version Across the Tree
When a transitive dependency pins an old lodash, you have a few levers. With npm, an overrides block forces resolution to a safe version across the whole tree:
{
"overrides": {
"lodash": "4.17.21"
}
}
Yarn offers resolutions for the same purpose. Use these deliberately: forcing a version can in rare cases break a dependency that relied on old behavior, so run your test suite after applying an override. For lodash specifically, 4.17.21 is API-compatible with the 4.x line, so overrides are usually low-risk. The cleaner long-term fix is upgrading the intermediate package to a release that already depends on a patched lodash.
Reducing Your Reliance on Lodash
A secondary consideration: modern JavaScript has absorbed much of what lodash was originally needed for. Native Array and Object methods, optional chaining, and the spread operator cover a large share of everyday use. Trimming unnecessary utility dependencies shrinks your attack surface and your bundle. This is not a reason to rip out a well-maintained library that is doing real work, but it is worth asking whether a single lodash helper justifies the dependency.
Catching This Automatically
Manually running npm ls per package does not scale across dozens of services. Software composition analysis reads your lockfiles and flags a vulnerable lodash version, transitive or direct, on every build. An SCA tool such as Safeguard can flag a buried 4.16.x copy that package.json never mentions, which is precisely the case humans miss. Our SCA product page explains how transitive matching works, and if you are weighing options, our comparison with Snyk covers what to look for in dependency coverage.
FAQ
Which lodash npm version is safe?
Use 4.17.21 or later. It resolves the prototype pollution advisories CVE-2019-10744 (fixed in 4.17.12) and CVE-2020-8203 (fixed in 4.17.20) along with the other known lodash issues.
What is prototype pollution in lodash?
It is a bug where crafted input manipulates Object.prototype through functions like defaultsDeep or zipObjectDeep, injecting properties that affect every object in the app. It can lead to bypassed logic or, in some cases, more serious downstream attacks.
How do I check which lodash version my project uses?
Run npm ls lodash. It lists every dependency path that pulls in lodash and the version each resolved to, so you can spot an old transitive copy even if your own package.json specifies a safe one.
How do I force a safe lodash version across my dependency tree?
Use an overrides block in npm (or resolutions in Yarn) pinning lodash to 4.17.21, then run your tests. The cleaner fix is upgrading the intermediate package that requires the old version.