CVE-2026-29063

What it actually does

Immutable.js versions before 3.8.3, 4.3.7, and 5.1.5 can allow prototype pollution when attacker-controlled object keys are processed through APIs such as mergeDeep(), mergeDeepWith(), merge(), Map.toJS(), and Map.toObject(). If malicious keys such as __proto__, constructor, or prototype are merged or converted without proper filtering, properties can be written onto shared JavaScript object prototypes rather than only the intended Immutable data structure or plain object. The practical effect depends on the consuming application: polluted prototype properties can alter authorization checks, feature flags, validation logic, object serialization, template rendering behavior, or other security-sensitive application logic. In vulnerable code paths, this may lead to confidentiality impact, application state manipulation, denial of service, or in rare cases remote code execution if the polluted property reaches a dangerous gadget in the application stack.

Why it matters to the business

Applications that use vulnerable Immutable.js versions to process untrusted JSON, API input, configuration, metadata, or user-supplied nested objects may be exposed to remote, unauthenticated compromise of application behavior. Because Immutable.js is a widely used JavaScript dependency that is often pulled in transitively by front-end and Node.js packages, exposure may exist even when teams do not directly import it. The CVSS score is critical, but EPSS is currently low and there is no known CISA KEV listing or ransomware association, so remediation should be prioritized based on whether the dependency is reachable from untrusted input, internet-facing services, authentication or authorization flows, or server-side JavaScript execution.

How an attack unfolds

An attacker first identifies an application endpoint, API, webhook, import function, or client-side workflow that accepts nested object data and passes it into Immutable.js merge or conversion APIs. The attacker then submits a crafted object containing prototype-targeting keys such as __proto__, constructor, or prototype. In vulnerable versions, the library may merge or materialize those keys in a way that modifies a shared JavaScript prototype. After pollution occurs, later application code may read attacker-influenced inherited properties as though they were legitimate object properties. The attacker then triggers the affected business logic, such as authorization decisions, configuration checks, validation routines, rendering paths, or data access operations, to obtain unauthorized data, bypass controls, corrupt application behavior, or cause service instability. Exploitation is highly application-dependent: the vulnerable library primitive enables prototype pollution, while the final security impact depends on the presence of exploitable application-level gadgets.

How to fix it

Upgrade Immutable.js to a patched version on the branch in use: 3.8.3 or later for the 3.x line, 4.3.7 or later for the 4.x line, and 5.1.5 or later for the 5.x line. Regenerate lockfiles and redeploy all applications, containers, serverless bundles, and front-end builds that include the vulnerable package. Because the package may be present transitively, inspect package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, bundled assets, and software composition analysis results for vulnerable immutable versions. If immediate upgrade is not possible, reject or sanitize untrusted keys named __proto__, prototype, and constructor before data reaches Immutable.js merge or conversion APIs; avoid passing untrusted objects directly into mergeDeep(), mergeDeepWith(), merge(), Map.toJS(), or Map.toObject(); and prefer schema validation that denies unknown nested properties. Treat sanitization as a temporary mitigation, not a substitute for upgrading.

How to confirm the fix worked

Confirm that every deployed artifact resolves immutable to version 3.8.3, 4.3.7, 5.1.5, or a later patched version. Validate with package-manager tooling such as npm ls immutable, yarn why immutable, pnpm why immutable, dependency scanning, and direct inspection of lockfiles and built container images. Test representative application paths that accept nested JSON to ensure prototype-pollution keys are rejected or safely ignored. A safe validation approach is to submit non-destructive payloads containing __proto__, constructor, and prototype keys in a controlled test environment and verify that no unexpected inherited properties appear on newly created JavaScript objects after the request is handled. Also confirm that CI/CD dependency policies fail builds when vulnerable immutable versions are introduced.

Typical attack path

1. Find an application feature that accepts attacker-controlled JSON, form data, webhook payloads, imported documents, or configuration-like nested objects.
2. Determine or infer that the data is processed through Immutable.js mergeDeep(), mergeDeepWith(), merge(), Map.toJS(), or Map.toObject().
3. Submit a crafted nested object containing prototype-pollution keys such as __proto__, constructor, or prototype.
4. Cause the vulnerable Immutable.js code path to merge or convert the malicious data into a JavaScript object context.
5. Trigger downstream application logic that reads inherited properties and treats them as trusted values.
6. Abuse the polluted property to bypass validation, alter authorization or configuration behavior, expose data, disrupt service, or reach another application-specific exploit gadget.

How to detect it

There is no universal post-exploitation artifact because prototype pollution affects application runtime behavior and the final impact depends on the consuming code. To look for prior exploitation, review HTTP access logs, API gateway logs, WAF logs, application logs, webhook ingestion logs, import-processing logs, and error telemetry for requests containing prototype-pollution keys such as __proto__, constructor, prototype, constructor.prototype, or nested JSON structures combining constructor and prototype. Pay special attention to endpoints that accept JSON bodies, bulk import files, user preferences, metadata, filters, search parameters, workflow definitions, integration payloads, or configuration-like input. Correlate suspicious payloads with unexpected authorization successes, privilege changes, access to unusual records, spikes in 4xx/5xx errors, Node.js process crashes, memory growth, abnormal response fields, or application logs showing unexpected inherited property values. For server-side JavaScript services, examine APM traces and exception logs around vulnerable merge or conversion calls, especially mergeDeep(), mergeDeepWith(), merge(), Map.toJS(), and Map.toObject(). For client-side-only exposure, review telemetry, CSP reports, and application error reporting for malicious input propagation, while recognizing that client-side logs may be incomplete. If payloads are found, reproduce the request in an isolated patched and unpatched test environment to determine whether the specific application code path was exploitable.

• __proto__
• "__proto__"
• %5F%5Fproto%5F%5F
• constructor.prototype
• "constructor":{"prototype"
• "constructor"\s*:\s*\{\s*"prototype"
• "prototype"\s*:
• mergeDeep(
• mergeDeepWith(
• Map.toJS(
• Map.toObject(
• Cannot set property '__proto__'
• prototype pollution
• polluted prototype

What your security team should do

• Inventory all applications and packages that include immutable-js/immutable, including transitive dependencies and bundled front-end assets.
• Prioritize patching internet-facing, API-driven, server-side JavaScript, authentication, authorization, data-processing, webhook, and import workflows that process untrusted nested objects.
• Upgrade Immutable.js to 3.8.3, 4.3.7, 5.1.5, or later, then rebuild and redeploy affected artifacts from clean dependency lockfiles.
• Add dependency-scanning rules to block immutable versions earlier than 3.8.3, 4.3.7, and 5.1.5.
• Add request validation or WAF/API-gateway detections for prototype-pollution keys in JSON and form payloads, especially __proto__, constructor.prototype, and nested constructor/prototype combinations.
• Review application code for use of mergeDeep(), mergeDeepWith(), merge(), Map.toJS(), and Map.toObject() on untrusted data.
• Search logs for prior suspicious requests containing prototype-pollution keys and correlate them with authorization anomalies, unusual errors, data access spikes, or process crashes.
• If suspicious exploitation is found, rotate secrets potentially exposed through the affected application, review affected user sessions, and perform targeted application forensic analysis.