Lodash 4.17.21 vulnerabilities are widely misunderstood: 4.17.21 is the release that fixed the most famous lodash security bugs, which is exactly why so many projects pinned to it and then stopped thinking about it. For years that was a reasonable choice. More recently, newer advisories have reported issues that reach 4.17.21 itself, so treating it as permanently "the safe version" is no longer accurate. Here is the honest state of the lodash 4.17.21 vulnerability picture.
Why 4.17.21 became the version everyone trusted
Lodash is one of the most depended-upon packages in the JavaScript ecosystem. When two serious issues were disclosed in the 4.17.x line, 4.17.21 was the release that resolved the last of them, so it became the de facto minimum safe version and got pinned into thousands of lockfiles.
Two CVEs drove that:
- CVE-2020-8203 — prototype pollution in functions like
_.zipObjectDeepand_.set. Prototype pollution lets an attacker inject properties ontoObject.prototype, which downstream code may then trust, leading to denial of service or, in the wrong context, code execution. This was addressed in the 4.17.19/4.17.20 range. - CVE-2021-23337 — command injection through
_.template. A crafted template option could execute arbitrary code during template compilation. This one was fixed in 4.17.21, which is why that specific version number stuck in people's memory as the fix.
So if you are on 4.17.21, you are already past both of those. Upgrading to 4.17.21 was, at the time, the correct remediation, and much of the "lodash 4.17.21 vulnerability" chatter you find online is actually describing bugs that 4.17.21 fixed, not bugs in it.
What 4.17.21 does NOT protect you from
The nuance most guides miss: being on 4.17.21 does not mean you are done forever. A few things are worth knowing.
First, the _.template fix in CVE-2021-23337 addressed one injection path, but security researchers have continued to probe _.template. Later analysis noted that validation was applied to some options but not to every key, meaning template compilation on attacker-controlled input remains something to avoid entirely rather than something to rely on a version bump to make safe. The practical takeaway is simple: never feed untrusted data into _.template.
Second, and more importantly, newer prototype-pollution advisories in the 2025–2026 window have been reported against the _.unset and _.omit functions in lodash versions that include 4.17.21. One such advisory (tracked as CVE-2025-13465) describes prototype pollution reachable through those functions across the 4.x line up to and including recent releases, with follow-up findings noting that array-wrapped path segments could bypass an initial guard. Vendors like IBM have published bulletins referencing these against products that bundle lodash-4.17.21.tgz.
Verify the exact affected ranges and fixed version against the GitHub advisory database or NVD before you act, because prototype-pollution advisories are frequently re-scoped as researchers refine the affected paths. The point is directional: 4.17.21 is no longer guaranteed to be clean.
How to check what you actually ship
You cannot reason about your exposure until you know which lodash resolves in your tree, including transitively:
npm ls lodash
# or, to find every path that pulls it in
npm why lodash
It is common to find multiple lodash versions in one lockfile because different dependencies request different ranges. A direct dependency you upgraded can be undermined by a transitive one that stays pinned to an older version. This transitive layering is precisely where a version bump in package.json fails to protect you, and where an SCA tool such as Safeguard earns its place by flagging every resolved instance, not just the one you declared.
Remediation options
Upgrade. If a fixed release addressing the newer _.unset/_.omit advisories is available for your range, move to it. Confirm the fixed version from the advisory rather than guessing a number.
Reduce blast radius. Many projects import all of lodash for one or two functions. Importing only what you use, or replacing a handful of helpers with native JavaScript, shrinks the amount of lodash surface you carry. Object.assign, spread syntax, Array.prototype.flat, and optional chaining cover a large fraction of what people reach for lodash to do.
Harden against prototype pollution generally. Freeze prototypes where feasible (Object.freeze(Object.prototype) in tightly controlled apps), avoid deep-merging untrusted objects, and validate the shape of external input before it reaches any deep-set or deep-merge helper. These defenses matter regardless of which library version you run.
For teams building a repeatable process around this, our guide on handling transitive dependency risk walks through the same pattern for a different ecosystem.
The bigger lesson
The lodash 4.17.21 story is a clean illustration of why "pin to the known-good version and forget it" fails over time. A version that was genuinely safe when you pinned it can accumulate new disclosures years later. Continuous scanning, not one-time remediation, is what keeps a dependency honest.
FAQ
Is lodash 4.17.21 safe to use?
It fixed the well-known CVE-2021-23337 command injection and the earlier CVE-2020-8203 prototype pollution. However, newer advisories reported in 2025–2026 describe prototype pollution reaching 4.17.21 through _.unset and _.omit, so it is no longer guaranteed clean. Check current advisories for your version.
What did lodash 4.17.21 actually fix?
It fixed CVE-2021-23337, a command injection vulnerability in the _.template function. Earlier prototype-pollution issues such as CVE-2020-8203 were fixed in the preceding 4.17.19/4.17.20 releases.
Can I still use _.template safely?
Only with input you fully control. Do not pass untrusted data into _.template. The safest approach is to avoid it for any user-influenced content entirely.
How do I find lodash in my dependency tree?
Run npm ls lodash or npm why lodash. You will often see more than one version because transitive dependencies request different ranges, and older transitive copies can undermine a direct upgrade.