GHSA-2m96-9w4j-wgv7

What it actually does

lodash.merge versions before 4.6.1 can merge attacker-controlled object properties such as __proto__, constructor, or prototype into JavaScript object prototypes. If an application passes untrusted JSON or request-derived objects into lodash.merge, an attacker may pollute Object.prototype and cause unexpected properties to appear on many objects at runtime. The concrete impact depends on how the application uses object properties afterward: common outcomes include authorization or validation bypass, application logic manipulation, denial of service, and, in higher-risk application patterns, possible code execution through polluted configuration objects used by templating, command execution, or deserialization paths.

Why it matters to the business

Applications that use vulnerable lodash.merge versions may be exposed to manipulation of server-side application behavior if they merge untrusted input. Because this is a widely used npm utility and the issue has been public since 2020, remaining exposure usually indicates stale dependency management and may exist indirectly through transitive dependencies. Although it is not listed in CISA KEV and no exploit maturity was provided, prototype pollution flaws are well understood and can be exploited quickly when a reachable merge path exists.

How an attack unfolds

An attacker first identifies an application endpoint or workflow that accepts structured input such as JSON, query parameters, form data, or configuration-like objects. They then submit a crafted object containing prototype-related keys, for example __proto__ or constructor.prototype, with attacker-chosen properties. If the application merges that object using a vulnerable lodash.merge version, the merge operation writes those properties onto a shared JavaScript prototype rather than only onto the intended destination object. Subsequent application code may then read polluted properties as if they were legitimate values. Depending on the application logic, this can alter security checks, change defaults, bypass validation, crash processes, or influence dangerous sinks such as template rendering or child process options.

How to fix it

Upgrade lodash.merge to version 4.6.1 or later wherever it is used, including transitive dependency paths where possible. Regenerate package lockfiles after upgrading and redeploy affected applications. If immediate upgrade is not possible, avoid passing untrusted input directly to lodash.merge, reject or strip dangerous keys such as __proto__, prototype, and constructor before merging, use object schemas with allowlists, and consider creating objects with null prototypes for untrusted dictionaries. Add automated dependency scanning in CI/CD to prevent reintroduction of lodash.merge versions earlier than 4.6.1.

How to confirm the fix worked

Confirm that dependency manifests and lockfiles resolve lodash.merge to 4.6.1 or later. Run package manager checks such as npm ls lodash.merge, npm audit, and software composition analysis scans against production build artifacts, not only source repositories. Review reachable code paths for calls to merge functions that process request body, query string, headers, cookies, uploaded JSON, or user-controlled configuration. Where safe, test representative endpoints with benign prototype pollution canaries and confirm that properties do not appear on unrelated empty objects or affect subsequent requests. Validate that deployed containers, serverless bundles, and packaged artifacts no longer contain vulnerable lodash.merge versions.

Typical attack path

1. Identify a web application or API that accepts attacker-controlled structured input.
2. Find a code path where that input is merged into another object using lodash.merge before version 4.6.1.
3. Send a payload containing prototype pollution keys such as __proto__, constructor, or prototype.
4. Cause the vulnerable merge operation to add attacker-controlled properties to Object.prototype or another shared prototype.
5. Trigger later application behavior that reads the polluted property, such as authorization checks, feature flags, validation defaults, template options, or process configuration.
6. Use the altered behavior to bypass controls, disrupt service, or escalate impact depending on reachable application sinks.

How to detect it

Because this is a library vulnerability, there is no universal host-level indicator proving exploitation. Detection should focus on application, API gateway, WAF, reverse proxy, and load balancer logs containing prototype pollution payloads in request bodies, query strings, form fields, headers, cookies, or uploaded JSON. Search for requests containing keys such as __proto__, constructor.prototype, prototype, or nested encodings of those terms. Correlate suspicious requests with application errors, crashes, unusual authorization outcomes, unexpected feature-flag behavior, configuration changes, or anomalous downstream process execution. For forensic review, inspect package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, deployed node_modules directories, container layers, and build artifacts for lodash.merge versions earlier than 4.6.1. If application telemetry is available, review traces around lodash.merge calls that processed external input and look for object properties appearing unexpectedly across unrelated requests.

• __proto__
• constructor.prototype
• constructor[prototype]
• prototype[
• prototype.
• lodash.merge@4.6.0
• lodash.merge@4.5.
• lodash.merge@4.4.
• lodash.merge@4.3.
• lodash.merge@4.2.
• lodash.merge@4.1.
• lodash.merge@4.0.
• node_modules/lodash.merge/package.json
• "lodash.merge": "4.6.0"
• "lodash.merge":"4.6.0"
• "lodash.merge": "^4.6.0"
• "lodash.merge": "~4.6.0"
• "version": "4.6.0"

What your security team should do

• Inventory all applications and packages that include lodash.merge, including transitive npm dependencies and bundled frontend or backend artifacts.
• Prioritize remediation for internet-facing APIs, administrative interfaces, multi-tenant services, and any application that merges user-supplied JSON or configuration data.
• Upgrade lodash.merge to 4.6.1 or later and redeploy affected services.
• Add dependency scanning and lockfile enforcement to CI/CD so vulnerable versions cannot be reintroduced.
• Review application code for unsafe deep merge patterns using any library, not only lodash.merge, when handling untrusted input.
• Add input validation or schema allowlisting to reject prototype-related keys before object merge operations.
• Search historical logs for prototype pollution payloads and investigate any correlated application errors, authorization anomalies, or unexpected configuration changes.