CVE-2026-2950

What it actually does

Lodash 4.17.23 and earlier incompletely blocks prototype-pollution-style paths in _.unset and _.omit. The prior guard checks string path members, but attacker-controlled array-wrapped path segments can bypass that validation and cause deletion of properties from built-in JavaScript prototypes such as Object.prototype, Number.prototype, or String.prototype. This flaw does not allow direct overwriting of prototype behavior, but deleting inherited properties can still alter application logic, break assumptions in dependent code, trigger exceptions, or disable expected safeguards when an application passes untrusted path input into these Lodash functions.

Why it matters to the business

Applications that expose user-controlled field paths to Lodash _.unset or _.omit may be vulnerable to logic disruption, data-processing errors, failed requests, and potential bypasses of application checks that depend on inherited properties. Because Lodash is widely embedded directly and transitively in JavaScript applications, exposure may exist through application code or downstream dependencies even when teams do not call the affected functions directly. The current EPSS is low, the issue is not listed in CISA KEV, and no exploit maturity is reported, but remediation should still be prioritized for internet-facing services and shared libraries because the vulnerable package is common and the attack requires low complexity once a reachable code path exists.

How an attack unfolds

An attacker first identifies an application endpoint, API parameter, configuration field, or serialized object that is later used as a path argument to Lodash _.unset or _.omit. Instead of supplying a normal string path, the attacker submits a crafted path using array-wrapped segments that include prototype-related members. In vulnerable Lodash versions, this bypasses the string-member validation added for the earlier related issue and causes Lodash to traverse into built-in prototypes. The attacker then causes selected prototype properties to be deleted. After deletion, subsequent application code that relies on those inherited properties may behave incorrectly, throw runtime errors, skip expected logic, or produce altered results. Exploitation is highly application-dependent: systems that do not pass attacker-controlled paths into _.unset or _.omit are not practically exploitable, while systems that do may be exposed over the network without authentication if the vulnerable code path is reachable from unauthenticated requests.

How to fix it

Upgrade Lodash to version 4.18.0 or later wherever it is used, including direct and transitive dependencies. Also update related packages where present, including lodash-es, lodash-amd, and lodash.unset, to fixed versions when available from the package maintainers. Regenerate lockfiles after upgrading and redeploy affected applications. There is no reliable workaround for the vulnerable Lodash behavior itself. As defense in depth, do not pass untrusted user input directly as a path to _.unset, _.omit, or similar object-path utilities; reject or canonicalize prototype-related path members such as __proto__, prototype, and constructor; and prefer allow-listed field names over arbitrary object paths.

How to confirm the fix worked

Confirm remediation by inspecting package manifests, lockfiles, SBOMs, and built artifacts for Lodash versions 4.17.23 or earlier. Use package-manager commands such as npm ls lodash lodash-es lodash-amd lodash.unset, yarn why lodash, or pnpm why lodash to identify direct and transitive copies. Validate that runtime bundles no longer include vulnerable Lodash versions and that lockfiles resolve Lodash to 4.18.0 or later. In non-production testing, exercise application inputs that are mapped to object paths and verify that prototype-related or nested array path segments are rejected before reaching Lodash. Also run dependency scanning in CI/CD and fail builds that introduce vulnerable Lodash ranges.

Typical attack path

1. Discover that the application uses Lodash 4.17.23 or earlier, lodash-es, lodash-amd, or lodash.unset in request-processing logic.
2. Find an input field, API parameter, JSON body member, query parameter, or configuration value that is treated as a Lodash object path.
3. Submit crafted path input using array-wrapped prototype-related path segments to bypass string-only validation.
4. Trigger _.unset or _.omit execution against the attacker-controlled path.
5. Delete a property from a built-in JavaScript prototype.
6. Abuse the resulting application behavior change, such as request failures, disabled logic assumptions, or inconsistent data handling.

How to detect it

There is no universal host artifact that proves exploitation because successful exploitation depends on how an application passes input into Lodash. Review application, API gateway, WAF, reverse proxy, and error logs for requests containing prototype-pollution path members, especially when encoded in array syntax or nested JSON arrays. Focus on endpoints that accept object field paths, JSON patch-like operations, filters, selectors, form field names, customization rules, or user-controlled configuration. Look for strings such as __proto__, constructor, prototype, Object.prototype, Number.prototype, or String.prototype appearing in request bodies, query strings, form keys, or serialized JSON arrays. Correlate suspicious requests with application errors such as TypeError exceptions, unexpected missing methods, increased 4xx/5xx responses, worker restarts, or abnormal request failures after the request. In code-level forensics, review telemetry around calls to _.unset and _.omit where the path argument originated from an external request. Treat payload indicators as suspicious rather than conclusive, because these strings can appear in benign developer traffic and exploitation effects are application-specific.

• __proto__
• constructor.prototype
• Object.prototype
• Number.prototype
• String.prototype
• ["__proto__"]
• ["constructor"]
• ["prototype"]
• %5B%22__proto__%22%5D
• %5B%22constructor%22%5D
• %5B%22prototype%22%5D
• _.unset
• _.omit
• lodash.unset

What your security team should do

• Inventory all JavaScript applications, services, serverless functions, frontend bundles, and shared packages for Lodash 4.17.23 or earlier and related affected packages.
• Prioritize upgrades for internet-facing services and APIs that accept JSON bodies, query parameters, user-defined filters, object field selectors, patch operations, or dynamic configuration paths.
• Upgrade Lodash to 4.18.0 or later and regenerate lockfiles to remove vulnerable transitive resolutions.
• Search application code for _.unset, unset(, _.omit, omit(, lodash.unset, and dynamic object-path handling where user input may be passed as the path argument.
• Add input validation that blocks prototype-related path members and replace arbitrary path-based mutation with allow-listed fields where feasible.
• Review web, API gateway, and application logs for attempted prototype-pollution payloads, especially array-style path syntax containing __proto__, constructor, or prototype.
• Add dependency-scanning policy controls so vulnerable Lodash versions cannot be reintroduced through transitive dependencies.