lodash-es @4.17.23
Lodash exported as ES modules.
Maintainers
Keywords
Risk Dispositions (2 applicable to this version, 1 other)
Accepted rules are downgraded to INFO on future analyses; rejected rules escalate to CRITICAL.
| Rule | Source | Disposition | Author | Reason | |
|---|---|---|---|---|---|
osv:GHSA-r5fr-rjxr-66jc |
osv | reject | AI | AI (osv): HIGH severity code injection in _.template; affected range covers all versions < 4.18.0; fix available. Verdict generalizes to all affected versions. | |
osv:GHSA-f23m-r3pf-42rh |
osv | reject | AI | AI (osv): Prototype pollution via array path bypass; affected range covers versions < 4.18.0; fix available. Verdict generalizes. |
Show 1 disposition(s) that do not match any finding on this version
| Rule | Source | Disposition | Author | Reason | |
|---|---|---|---|---|---|
osv:GHSA-xxjr-mmjv-4gpg |
osv | reject | AI | AI (osv): Prototype pollution in _.unset/_.omit; affected range covers versions < 4.17.23; fix available. Verdict generalizes. |
SAST Findings (4)
[Always reject] CVSS 6.5 (MEDIUM) — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L ### Impact Lodash versions 4.17.23 and earlier are vulnerable to prototype pollution in the `_.unset` and `_.omit` functions. The fix for [CVE-2025-13465](https://github.com/lodash/lodash/security/advisories/GHSA-xxjr-mmjv-4gpg) only guards against string key members, so an attacker can bypass the check by passing array-wrapped path segments. This allows deletion of properties from built-in prototypes such as `Object.prototype`, `Number.prototype`, and `String.prototype`. The issue permits deletion of prototype properties but does not allow overwriting their original behavior. ### Patches This issue is patched in 4.18.0. ### Workarounds None. Upgrade to the patched version.
[Always reject] CVSS 8.1 (HIGH) — CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H ### 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. The fix applies two changes: 1. Validate `importsKeys` against the existing `reForbiddenIdentifierChars` regex (same check already used for the `variable` option) 2. Replace `assignInWith` with `assignWith` when merging imports, so only own properties are enumerated ### Workarounds Do not pass untrusted input as key names in `options.imports`. Only use developer-controlled, static key names.
This version was published by a different npm account than previous versions on 2026-01-21. This could indicate a legitimate maintainer transition or an account compromise.
Package was published without Sigstore provenance. Consider requesting the maintainer enable provenance via CI/CD.
Review Summary
Risk score: 100 (capped from 128). Findings: 2 critical (+80), 1 high (+25), 2 medium (+20), 1 low (+3).
Commit: a89086873c55 Browse source
Published to npm: