CVE-2026-59880: Immutable.js Hash Collision DoS Vulnerability (CVSS 7.5)

Technical summary

The vulnerability stems from how Immutable.Map and Immutable.Set handle hash collisions. When multiple keys produce the same 32-bit hash value, they are stored in a HashCollisionNode and scanned linearly during insertion, lookup, and merge operations. An attacker who controls the keys—such as through user-supplied objects passed to Immutable.Map(), Immutable.fromJS(), state.merge(), or mergeDeep—can engineer colliding keys using known hash function properties. This bypasses the O(1) average-case performance guarantee and degrades operations to O(n) time complexity, where n is the number of colliding keys. The hash function weakness allows practical construction of collision sets without requiring hash preimage attacks.

Business impact

Applications using Immutable.js for state management, caching, or data transformation become vulnerable to resource exhaustion attacks. If an application accepts user-controlled data and converts it to Immutable structures—common in Redux/React patterns, server-side state aggregation, or API processing—an attacker can send payloads that consume disproportionate CPU. This can degrade performance across shared infrastructure, trigger autoscaling costs, or cause service timeouts. The attack surface is particularly broad because the vulnerable APIs (merge, fromJS) are idiomatic usage patterns, and no special privileges are required.

Affected systems

All applications using immutable-js library versions prior to 4.3.9 (in the 4.x line) or prior to 5.1.8 (in the 5.x line) are affected. This includes Node.js applications, server-side rendering systems, and browser-based applications that bundle the library. The vulnerability is triggered when untrusted input is passed to Immutable.Map(), Immutable.fromJS(), merge operations, or mergeDeep operations. Organizations should inventory all direct and transitive dependencies on immutable-js across their codebase.

Exploitability

Exploitability is high. The attack requires only network access and no authentication. An attacker can craft a JSON payload or object with colliding hash keys and submit it to any endpoint that processes it through Immutable.js constructors or merge operations. No complex exploitation techniques or user interaction is required. The linear scanning of collision nodes makes the attack deterministic and reliable. However, practical impact depends on application architecture—some applications may have timeouts or resource limits that mitigate the worst effects.

Remediation

Upgrade immutable-js to version 4.3.9 or later (for 4.x users) or 5.1.8 or later (for 5.x users). These versions implement a more robust collision handling strategy that prevents attackers from degrading performance through hash collision attacks. After upgrading, verify that your build tools and package managers correctly resolve the new version across all dependencies. Consider implementing input validation and size limits on user-supplied objects before converting them to Immutable structures as a defense-in-depth measure.

Patch guidance

Check your package.json and lock files for the installed version of immutable. For npm projects, run `npm list immutable` to verify the current version. Update using `npm update immutable` to pull the latest compatible version within your specified semver range, or use `npm install [email protected]` (or `[email protected]`) to pin a specific fixed version. If immutable is a transitive dependency, check the package-lock.json and ensure your direct dependencies are updated to versions that require the patched immutable version. Test your application after updating, particularly any code paths that merge or construct Immutable structures from external data.

Detection guidance

Monitor application CPU usage and latency during normal operations to establish a baseline. Look for sudden spikes in CPU consumption or request latency that correlate with specific user inputs or API calls that construct or merge Immutable structures. Server logs may show individual requests taking unusually long to complete. Consider implementing metrics on the size and composition of objects passed to Immutable.fromJS() and merge() operations. In a WAF or API gateway, monitor for POST/PUT requests with unusually large payloads or repetitive key patterns that might indicate collision-based payloads.

Why prioritize this

This vulnerability scores HIGH (CVSS 7.5) due to high availability impact, network accessibility, and low complexity. The practical exploitability is straightforward—no privilege escalation or local access required. The widespread use of Immutable.js in modern JavaScript applications amplifies exposure. While this is not an integrity or confidentiality breach, the ability to remotely cause denial of service affects business continuity. Organizations running user-facing or API-driven applications should prioritize this promptly.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects HIGH severity: Network-accessible attack vector (AV:N), low attack complexity (AC:L), no privilege requirements (PR:N), no user interaction needed (UI:N), and impacts only availability (A:H). The confidentiality and integrity ratings are unaffected because the attack does not expose data or corrupt it—it only consumes resources. The HIGH severity is justified because denial-of-service attacks can disrupt critical services, but the score would be CRITICAL if the attack also compromised integrity or confidentiality.

Frequently asked questions