GHSA-h726-x36v-rx45

What it actually does

lodash.merge versions before 4.6.2 can recursively merge attacker-controlled object keys such as __proto__, constructor, or prototype into JavaScript object prototypes. This is a prototype pollution vulnerability: instead of only changing the intended target object, malicious input can alter Object.prototype or other shared prototypes, causing newly created objects to inherit attacker-supplied properties. The concrete impact depends on how the consuming application uses merged objects, but can include authorization bypass, logic manipulation, denial of service, configuration tampering, or, in specific unsafe patterns, code execution through polluted options passed into sensitive APIs.

Why it matters to the business

Applications that accept untrusted JSON or object-like input and merge it with lodash.merge may behave incorrectly or insecurely after processing a crafted request. Business consequences can include unauthorized access to application functionality, disrupted service, corrupted application logic, or downstream compromise if polluted properties influence security-sensitive behavior. Although this advisory is not listed in CISA KEV and no exploit maturity was provided, the package is widely used in the npm ecosystem, so vulnerable transitive dependencies may exist even when the package is not directly imported.

How an attack unfolds

An attacker first identifies an application endpoint, API, webhook, configuration import, or other feature that accepts structured input and passes that input into lodash.merge. The attacker submits a crafted object containing prototype-modifying keys such as {"__proto__":{"polluted":"true"}} or nested variants using constructor.prototype. In vulnerable versions, lodash.merge recursively processes those keys and writes attacker-controlled properties onto a shared JavaScript prototype. After pollution, unrelated objects created or inspected by the application may appear to contain the injected property. The attacker then attempts to make the polluted property influence application behavior, such as default authorization flags, template options, feature toggles, request handling, validation decisions, or error paths. The final impact is application-specific: some applications may only experience benign property pollution, while others may allow privilege escalation, denial of service, or deeper compromise if polluted values are later trusted by dangerous code paths.

How to fix it

Upgrade lodash.merge to version 4.6.2 or later. If lodash.merge is present transitively, update the parent package that depends on it, refresh the lockfile, and verify the resolved dependency is no longer vulnerable. Where immediate upgrade is not possible, reject or sanitize untrusted object keys including __proto__, prototype, and constructor before merging; avoid deep-merging untrusted input into application defaults or security-sensitive objects; use schema validation with additionalProperties controls; and prefer safe merge utilities that explicitly block prototype mutation. In npm projects, run npm audit or an equivalent SCA tool, update package-lock.json or npm-shrinkwrap.json, and redeploy rebuilt artifacts so the fixed dependency is actually in production.

How to confirm the fix worked

Confirm the installed dependency resolves to lodash.merge 4.6.2 or later using package manager output such as npm ls lodash.merge, yarn why lodash.merge, pnpm why lodash.merge, or software composition analysis results. Inspect package-lock.json, yarn.lock, pnpm-lock.yaml, and built container or serverless artifacts to ensure no vulnerable lodash.merge version remains. For application-level validation, test representative merge paths with payloads containing __proto__ or constructor.prototype and verify Object.prototype is not modified after processing. A simple safe-state check is that evaluating an unrelated empty object after the request does not reveal attacker-supplied inherited properties. Also confirm input validation rejects prototype-pollution keys in all exposed JSON or object-import paths.

Typical attack path

1. Find an application feature that accepts JSON, form-encoded, or object-like input.
2. Determine whether the input is merged into application state, defaults, configuration, session data, or request objects using lodash.merge.
3. Send a crafted payload containing prototype pollution keys such as __proto__, constructor, or prototype.
4. Cause the vulnerable merge operation to write attacker-controlled properties onto a shared JavaScript prototype.
5. Trigger a subsequent application code path that reads the polluted inherited property.
6. Abuse the resulting behavior change, such as bypassing checks, changing configuration, causing errors, or influencing sensitive operations.

How to detect it

Detection is application-specific because successful exploitation usually appears as crafted input followed by abnormal application behavior rather than a universal file or process artifact. Review HTTP access logs, API gateway logs, WAF events, reverse proxy logs, application request logs, exception traces, and audit logs for requests containing prototype pollution keys such as __proto__, constructor.prototype, or nested prototype fields. Pay particular attention to JSON request bodies, query strings, form fields, webhook payloads, and import/configuration uploads. Correlate suspicious requests with subsequent authorization anomalies, unexpected feature-flag or configuration changes, increases in 4xx/5xx errors, process crashes, memory growth, or unusual template/rendering errors. In Node.js applications, inspect runtime and error logs for unexpected inherited properties appearing in serialized objects or stack traces. If logs are available, search around the time of suspicious payloads for the same source IP, user account, API token, or session repeatedly probing variations of __proto__, constructor, and prototype. Because no public exploitation maturity or KEV status was provided, treat positive payload matches as suspicious reconnaissance or attempted exploitation, then validate whether vulnerable versions and exploitable merge paths existed at the time.

• __proto__
• constructor.prototype
• "constructor":{"prototype"
• "__proto__"
• %5F%5Fproto%5F%5F
• __proto__[
• constructor[prototype]
• prototype.polluted
• "polluted":true
• Object.prototype

What your security team should do

• Prioritize upgrading lodash.merge to 4.6.2 or later across direct and transitive npm dependencies.
• Search all package manifests and lockfiles for lodash.merge versions below 4.6.2, including vendored code and container build artifacts.
• Identify application endpoints that accept structured user input and deep-merge it into defaults, configuration, authorization context, session objects, or template/rendering options.
• Add input validation or sanitization that blocks __proto__, constructor, and prototype keys before any merge operation.
• Add regression tests for prototype pollution payloads against critical request handlers and import/configuration features.
• Monitor web, API gateway, WAF, and application logs for prototype-pollution probe strings, especially repeated attempts using __proto__ or constructor.prototype.
• If suspicious payloads are observed, perform incident review focused on application behavior changes, unexpected authorization decisions, errors, crashes, and configuration anomalies after the request time.