CVE-2026-59880 in Immutable.js
Summary
by MITRE • 07/08/2026
Immutable.js provides many Persistent Immutable data structures. Prior to 4.3.9 and 5.1.8, Immutable.Map and Immutable.Set keep keys that share the same 32-bit hash in a HashCollisionNode collision bucket that is scanned linearly, allowing an attacker who controls keys inserted into a Map, such as through Immutable.Map(obj), Immutable.fromJS(obj), state.merge(userObject), or mergeDeep, to craft many colliding keys and degrade insertion and lookup to consume disproportionate CPU. This issue is fixed in versions 4.3.9 and 5.1.8.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/08/2026
This vulnerability affects the Immutable.js library, a popular JavaScript implementation of persistent immutable data structures that provides developers with efficient ways to manage state in applications. The flaw resides in how the library handles hash collisions within its Map and Set data structures, specifically in versions prior to 4.3.9 and 5.1.8. When multiple keys produce identical 32-bit hash values, these structures store them in HashCollisionNode collision buckets that require linear scanning during lookup operations. This design creates a potential denial of service scenario where an attacker can craft malicious input containing many colliding hash keys, causing the library to degrade from optimal O(log n) performance to O(n) performance for insertion and lookup operations.
The technical implementation of this vulnerability stems from the library's use of a hash table with linear collision resolution. When multiple keys hash to the same value, the system stores them in a linked list structure within the HashCollisionNode bucket. As more colliding keys are added, each lookup operation must scan through the entire bucket sequentially, creating a quadratic time complexity scenario that can be exploited to consume excessive CPU resources. This behavior directly violates the expected performance characteristics of hash-based data structures and represents a classic example of a hash collision attack pattern.
The operational impact of this vulnerability extends beyond simple performance degradation to potential system compromise. Attackers who control input data passed to Immutable.Map or Immutable.Set constructors, such as through user-provided objects in state.merge() operations or Immutable.fromJS() parsing, can craft specially designed key sets that trigger the worst-case collision scenarios. This vulnerability is particularly dangerous in web applications where user input directly feeds into immutable data structures, enabling attackers to perform resource exhaustion attacks that could affect application availability and responsiveness.
The fix implemented in versions 4.3.9 and 5.1.8 addresses this issue by introducing more robust collision handling mechanisms that prevent the linear scanning behavior described above. These updates likely employ techniques such as dynamic resizing of collision buckets, improved hash functions, or alternative data structures for handling high collision scenarios. The vulnerability aligns with CWE-400, which describes "Uncontrolled Resource Consumption" and specifically relates to the improper handling of hash collisions that can lead to denial of service conditions. This issue also maps to ATT&CK technique T1499.004, "Application Exhaustion Flood," as it represents a method for exhausting application resources through controlled input manipulation.
Organizations using Immutable.js should immediately upgrade to versions 4.3.9 or 5.1.8 to protect against this vulnerability, particularly in applications that process untrusted user input through the affected data structure operations. Additionally, defensive programming practices such as input validation and rate limiting should be implemented to minimize potential impact even if legacy versions must be used temporarily. The vulnerability demonstrates the importance of considering worst-case performance scenarios when designing hash-based data structures and highlights how seemingly benign library features can create security risks when subjected to adversarial input patterns.