EUVD-2026-17610
GHSA-r5fr-rjxr-66jc
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Code injection prevention, sandbox exec
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv5 – Jun 30, 2026
Server-side code injection in Lodash's _.template function (lodash, lodash-es, lodash-amd and lodash.template, versions 4.0.0 to <4.18.0) lets an attacker execute arbitrary JavaScript at template-compilation time when an application passes untrusted input as options.imports key names. This is an incomplete-fix follow-on to CVE-2021-23337/GHSA-35jh-r3h4-6jhm: the original patch validated the variable option but left the imports key path flowing unchecked into the same Function() sink, and assignInWith's for..in merge also pulls in any prototype-polluted keys. Publicly available exploit code exists, but EPSS is only 0.07% (21st percentile) and CISA SSVC rates exploitation as none, reflecting that the dangerous pattern is uncommon in real deployments.
Earlier versions of this analysis (4)
Server-side code injection in Lodash (and the lodash-es, lodash-amd, and lodash.template distributions) versions 4.0.0 through 4.17.x allows attackers to execute arbitrary JavaScript at template compilation time when an application passes untrusted data as options.imports key names to _.template. This is the same Function() constructor sink that CVE-2021-23337 patched for the variable option, but the original fix never validated imports key names; a secondary prototype-pollution amplification exists because assignInWith enumerates inherited properties via for..in. Publicly available exploit code exists, but it is not in CISA KEV and EPSS is very low (0.07%, 21st percentile), indicating no widespread exploitation.
Server-side code injection in Lodash's _.template (versions 4.0.0 through 4.17.x) lets an attacker execute arbitrary code at template-compilation time when an application passes untrusted input as options.imports key names. The flaw is an incomplete fix for CVE-2021-23337: the earlier patch sanitized the variable option but left options.imports keys flowing unvalidated into the same Function() sink, and the assignInWith-based import merge also pulls in any Object.prototype-polluted keys via for..in. Publicly available exploit code exists, but EPSS is only 0.07% and CISA SSVC rates exploitation as 'none', indicating no observed in-the-wild activity despite the 9.8 CVSS.
Code injection in Lodash's _.template (versions 4.0.0 through 4.17.x, fixed in 4.18.0) lets an attacker run arbitrary JavaScript at template-compile time when an application passes untrusted input as options.imports key names, an injection sink that the CVE-2021-23337 fix left unguarded. The same assignInWith merge also copies polluted Object.prototype keys into the Function() constructor, creating a second path that turns any pre-existing prototype pollution into remote code execution. Publicly available exploit code exists (gist by rising-leviathan) but there is no public exploit identified as actively used in the wild; EPSS is very low at 0.07%.
Remote code execution in Lodash <4.18.0 allows unauthenticated attackers to execute arbitrary JavaScript code during template compilation by injecting malicious key names into options.imports parameter. The vulnerability bypasses the CVE-2021-23337 fix by exploiting an unvalidated code path that flows into the same Function() constructor sink. With CVSS 8.1 (High) and EPSS data not provided, this represents a significant supply chain risk for applications using Lodash's template functionality with untrusted input. No public exploit confirmed at time of analysis, though the technical details in the advisory provide a clear exploitation roadmap.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 8 packages in npm, rubygems, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Know when Lodash gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AC:H because exploitation needs the uncommon pattern of untrusted input as imports key names (or pre-existing prototype pollution); PR:N/UI:N as no attacker auth or victim interaction is required, and full RCE yields C/I/A:H.
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
8DescriptionNVD
Impact:
The fix for CVE-2021-23337 (https://github.com/advisories/GHSA-35jh-r3h4-6jhm) added validation for the variable option in _.template but did not apply the same validation to options.imports key names. Both paths flow into the same Function() constructor sink.
When an application passes untrusted input as options.imports key names, an attacker can inject default-parameter expressions that execute arbitrary code at template compilation time.
Additionally, _.template uses assignInWith to merge imports, which enumerates inherited properties via for..in. If Object.prototype has been polluted by any other vector, the polluted keys are copied into the imports object and passed to Function().
Patches:
Users should upgrade to version 4.18.0.
Workarounds:
Do not pass untrusted input as key names in options.imports. Only use developer-controlled, static key names.
Blast Radius
ecosystem impact- 224 npm packages depend on lodash (119 direct, 110 indirect)
- 4,398 npm packages depend on lodash-es (1,072 direct, 3,409 indirect)
- 37 npm packages depend on lodash-template (13 direct, 24 indirect)
- 257 npm packages depend on lodash.template (82 direct, 176 indirect)
Ecosystem-wide dependent count for version 4.0.0 and other introduced versions.
Executive ViewAI
Lodash versions 4.0.0-4.17.x contain a code injection vulnerability in the template function enabling remote code execution when untrusted data reaches vulnerable code. Publicly available exploit code exists; however, exploitation likelihood remains low per EPSS scoring and the dangerous attack pattern is uncommon in real deployments. Organizations using affected versions face potential system compromise and should prioritize patching this critical dependency.
Within 24 hours: identify all systems and applications running Lodash versions 4.0.0-4.17.x. Within 7 days: upgrade to Lodash 4.18.0 or later, prioritizing business-critical systems. Within 30 days: complete testing and confirm all instances are patched.
Apply vendor patch: Lodash 4.18.0 or later
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Code injection occurs when an application accepts user input and passes it directly into a language interpreter or evaluator without proper sanitization.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
Lodash versions prior to 4.17.21 are vulnerable to Command Injection via the template function. Rated high severity (CVS
Versions of lodash lower than 4.17.12 are vulnerable to Prototype Pollution. Rated critical severity (CVSS 9.1), this vu
Lodash versions up to 4.17.22 is affected by improperly controlled modification of object prototype attributes (prototyp
Prototype pollution attack when using _.zipObjectDeep in lodash before 4.17.20. Rated high severity (CVSS 7.4), this vul
lodash prior to 4.17.11 is affected by: CWE-400: Uncontrolled Resource Consumption. Rated medium severity (CVSS 6.5), th
lodash node module before 4.17.5 suffers from a Modification of Assumed-Immutable Data (MAID) vulnerability via defaults
Prototype pollution in Lodash 4.17.23 and earlier allows unauthenticated remote attackers to delete properties from buil
Same weakness CWE-94 – Code Injection
View allVendor StatusVendor
SUSE
Severity: High| Product | Status |
|---|---|
| SUSE Liberty Linux 9 | Fixed |
Exploit-DB