Immutable.js Hash Collision Denial of Service

Executive Summary

CVE-2026-59880 is a vulnerability in the Immutable.js library affecting Immutable.Map and Immutable.Set data structures before versions 4.3.9 and 5.1.8. The issue arises because these structures use a deterministic and predictable 32-bit hash function for keys, which allows an attacker to craft many keys that collide on the same hash value.

When many keys share the same hash, they are stored in a single collision bucket that is scanned linearly during insertion and lookup operations. This linear scanning causes performance degradation from near constant time (O(1)) to linear time (O(n)) per operation, and building or reading the entire set can degrade to quadratic time (O(n²)).

An attacker who controls keys inserted into a Map, for example through Immutable.Map(obj) or Immutable.fromJS(obj), can exploit this by crafting many colliding keys to consume disproportionate CPU resources, potentially causing denial of service by stalling the event loop in single-threaded environments like Node.js.

The vulnerability was fixed by introducing a per-process seeded secondary hash index for large collision buckets, which scatters entries and restores near-linear lookup performance, preventing the hash-flooding attack.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability primarily causes a denial-of-service (DoS) condition by allowing attackers to degrade performance and consume disproportionate CPU resources through crafted hash collisions. This impacts system availability but does not directly affect confidentiality or integrity of data.

Since the vulnerability affects availability, it could potentially impact compliance with standards and regulations that require maintaining system availability and resilience, such as HIPAA's Security Rule or GDPR's requirements for data availability and integrity.

However, there is no direct indication from the provided information that this vulnerability leads to unauthorized data access, disclosure, or modification, which are critical factors for compliance with GDPR or HIPAA.

Mitigations such as limiting request body size, restricting object key counts, and avoiding building Maps directly from untrusted keys can reduce the risk and help maintain compliance by preventing denial-of-service conditions.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can impact you by causing a denial of service (DoS) condition in applications using vulnerable versions of Immutable.js. An attacker can exploit the predictable hash collisions to degrade the performance of insertion and lookup operations in Immutable.Map or Immutable.Set, consuming excessive CPU resources.

In single-threaded runtimes such as Node.js, this CPU consumption can stall the event loop, effectively making the application unresponsive or significantly slowing it down.

Applications that ingest attacker-controlled object keys into Immutable data structures, for example by converting user input objects directly into Immutable Maps, are particularly vulnerable.

However, if attacker input is only stored as values under fixed keys, the vulnerability does not apply.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves performance degradation due to hash collisions in Immutable.js Map and Set data structures when processing attacker-controlled keys. Detection involves monitoring for unusually high CPU usage or degraded performance during operations involving Immutable.Map or Immutable.Set, especially when processing untrusted input.

Since the vulnerability is related to crafted keys causing hash collisions, one way to detect it is to analyze application logs or runtime metrics for spikes in CPU or latency during insertion or lookup operations in Immutable.js data structures.

There are no specific commands provided in the resources to detect this vulnerability directly on a network or system.

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation is to upgrade Immutable.js to version 4.3.9 or later, or 5.1.8 or later, where the vulnerability is fixed by introducing a per-process seeded secondary hash to prevent hash collision attacks.

As a workaround before upgrading, limit the size of request bodies, restrict the number and length of object keys, reject payloads with high cardinality, and avoid building Immutable.Map or Immutable.Set directly from untrusted object keys.

These steps reduce the risk of attackers crafting many colliding keys that degrade performance and cause denial of service.

Useful 0 Not Useful 0