CVE-2021-23337: Command injection in lodash template func...

CVE-2021-23337 is a command injection vulnerability in lodash, one of the most widely used JavaScript utility libraries in the npm ecosystem. The flaw lives in lodash's template function — the same code path used to compile JavaScript templates from strings — and affects all lodash versions prior to 4.17.21. An attacker who can influence the input passed to _.template(), whether through a template string, a configuration option, or data that flows into template compilation, can get arbitrary JavaScript executed in the context of the running application. Because _.template() ultimately builds and invokes a Function constructor, that arbitrary code execution can extend to shelling out to OS commands in server-side Node.js contexts, which is why the vulnerability is classified as command injection rather than a narrower "code injection."

What makes this CVE worth revisiting years later isn't novelty — it's reach. Lodash sits transitively beneath an enormous share of the npm dependency graph. Frameworks, build tools, CLIs, and countless internal libraries pull it in as a sub-dependency, often several layers removed from any package.json a developer actually looks at. A vulnerability in lodash's template engine doesn't just affect the small number of projects that call _.template() directly; it affects every consumer of every package that does, which is exactly the kind of transitive blast radius that makes software supply chain security hard to reason about with spreadsheets and manual audits alone.

Affected Versions and Components

• Affected: lodash versions prior to 4.17.21, including lodash's template and related methods that compile strings into executable template functions.
• Fixed in: lodash 4.17.21.
• Vulnerable component: _.template(), which lodash uses to precompile ERB-style JavaScript templates (<%= ... %> syntax) into callable functions using dynamic code generation.

The root issue is that lodash's template compiler does not adequately sanitize certain inputs before weaving them into the generated function body. Because the compiled template is ultimately executed as JavaScript, an attacker who controls template content — or certain options passed alongside it — can smuggle in code that runs when the template is rendered, rather than being treated as inert template data. In a Node.js server context, that arbitrary code execution can be used to invoke child processes and run OS-level commands, which is the basis for the "command injection" classification rather than a more limited XSS-style client-side issue.

It's worth noting that this fix shipped in the same 4.17.21 release that resolved several other lodash issues reported around the same period, including prototype pollution and ReDoS fixes. If your dependency tree pinned an older lodash to work around one of those, it's worth confirming the fix actually landed for this issue too rather than assuming a partial upgrade closed every gap.

Severity: CVSS, EPSS, and KEV Context

NVD's published CVSS v3.1 base score for CVE-2021-23337 is 7.2 (High), reflecting a vector where the vulnerability requires some privilege to exploit but yields high impact across confidentiality, integrity, and availability once triggered — consistent with a flaw that leads to arbitrary code/command execution rather than a read-only information disclosure.

On exploitability signals: CVE-2021-23337 is not currently listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, and we're not aware of confirmed evidence of widespread active exploitation in the wild. That said, absence from KEV should not be read as "safe to ignore" — KEV tracks vulnerabilities with confirmed exploitation, not the full universe of vulnerabilities that are technically exploitable or attractive to attackers. Given lodash's ubiquity, the practical risk from this CVE has always been less about targeted zero-day-style attacks and more about the sheer number of applications that inherit the vulnerable code path without anyone on the team realizing lodash's template function is in play at all. If you want current EPSS (Exploit Prediction Scoring System) figures for this CVE, check FIRST.org's EPSS data directly — those scores are recalculated regularly and we'd rather point you to the live source than quote a number that goes stale the day this post is published.

Timeline

• Discovery and disclosure: CVE-2021-23337 was reported and assigned as a command injection vulnerability in lodash's template functionality, building on prior scrutiny of lodash's template-compilation internals after earlier prototype pollution issues in the same area of the codebase.
• Fix released: The lodash maintainers shipped the fix in lodash 4.17.21, which addressed the template sanitization gap along with other outstanding issues in the library at the time.
• Advisory publication: The vulnerability was published with a corresponding GitHub Security Advisory and NVD entry, making it visible to standard software composition analysis (SCA) and dependency-scanning tooling.
• Ongoing exposure: Because lodash 4.17.21 has been available for an extended period, the residual risk today is almost entirely a function of organizations still running pinned, vendored, or transitively-locked versions of lodash below 4.17.21 — often without knowing it, because the dependency isn't declared directly in their own manifest.

Remediation

1. Upgrade lodash to 4.17.21 or later. This is the definitive fix. If you depend on lodash directly, bump the version in your manifest and lockfile.
2. Check transitive dependencies, not just direct ones. Run npm ls lodash (or the Yarn/pnpm equivalent) to find every place a vulnerable lodash version is pulled in beneath other packages. Many teams discover multiple, differently-pinned copies of lodash across their dependency tree.
3. Use overrides where you can't wait on upstream maintainers. npm supports the overrides field, yarn supports resolutions, and pnpm supports pnpm.overrides — all of which let you force a minimum lodash version across the entire tree even when an intermediate dependency hasn't bumped its own declared range yet.
4. Audit direct calls to _.template(). If your own code uses lodash's template function with any attacker-influenced input (user-submitted strings, uploaded config, data from an external API), treat that as a code path needing explicit review even after patching — never render templates built from fully untrusted strings without additional sandboxing.
5. Re-run SCA scans after remediation to confirm the fix actually resolved the finding across every workspace, monorepo package, and container image, since Docker layers and CI caches are a common place for stale, pre-patch versions to linger unnoticed.
6. Rebuild and redeploy affected artifacts. Patching package.json doesn't help if previously built container images or bundled artifacts containing the vulnerable lodash version remain in production; make sure the fix flows all the way to deployed workloads.

How Safeguard Helps

CVE-2021-23337 is a textbook example of why supply chain visibility has to go deeper than a top-level dependency list. The vulnerable code was buried in lodash's template compiler, several dependency layers removed from most applications' direct control, and the fix required teams to trace transitive paths they'd never had reason to inspect before.

Safeguard is built for exactly this problem. Our software composition analysis continuously maps your full dependency graph — direct and transitive — so that a vulnerability like CVE-2021-23337 surfaces immediately, with a clear picture of every package, workspace, and build artifact that pulls in the affected lodash version, not just the ones where it's declared in package.json. We correlate that exposure against severity data, exploitation signals, and your own deployment topology so your team can prioritize the services actually at risk instead of triaging every match by hand.

Beyond detection, Safeguard tracks remediation end-to-end: confirming that a version bump or override actually reaches your lockfiles, that CI rebuilds pick up the patched dependency, and that previously built images sitting in your registries get flagged and rebuilt rather than silently redeployed with the old, vulnerable code. For a vulnerability with the reach of a library as foundational as lodash, that continuous, artifact-level verification is the difference between a patch that looks complete in a pull request and one that's actually closed everywhere it matters across your software supply chain.