Immutable.Map and Immutable.Set use a deterministic 32-bit string hash without per-process salting, causing keys with colliding hashes to be stored in a single collision bucket scanned linearly. An attacker controlling keys can craft many colliding keys, degrading insertion and lookup from amortized O(1) to O(n) per operation and O(n²) for building or reading the entire set. This leads to CPU-bound denial of service in applications ingesting attacker-controlled keys into Immutable structures. The vulnerability affects all versions through 5.1.7. It is fixed in 5.1.8 by adding a per-process seeded secondary hash for large collision buckets, maintaining the public hash function and key equality checks unchanged.

Applications using Immutable.js to build Map or Set structures from attacker-controlled object keys can experience severe CPU consumption and event loop stalls, resulting in denial of service. This affects single-threaded runtimes such as Node.js where the event loop can be blocked. Applications that only use attacker input as values under fixed keys are not impacted. The vulnerability can be exploited by crafting many keys with colliding hashes, causing quadratic time complexity in insertion and lookup operations.

A fix is available in Immutable.js version 5.1.8, which introduces a per-process seeded secondary hash to mitigate large collision buckets and restore near-linear performance. Users should upgrade to version 5.1.8 or later. Before upgrading, as a workaround, limit request body size, restrict object key count and length, and avoid building Immutable.Map or Immutable.Set directly from untrusted object keys to reduce risk.