Immutable.Map and Immutable.Set use a deterministic, public 32-bit string hash without per-process salting, placing keys with identical hashes into a single collision bucket scanned linearly. Attackers controlling keys can craft large sets of colliding keys (e.g., strings like "Aa" and "BB" concatenated) that cause insertion and lookup operations to degrade from amortized O(1) to O(n), and building or reading the entire structure to O(n²). This leads to CPU-bound denial of service in applications ingesting attacker-controlled object keys into Immutable structures. The vulnerability affects all versions through 5.1.7. The fix in 5.1.8 adds a seeded secondary hash to index large collision buckets, restoring near-linear complexity without breaking the public hash or key equality semantics.

Applications using Immutable.js versions up to 5.1.7 that ingest attacker-controlled object keys into Immutable.Map or Immutable.Set can suffer CPU exhaustion and denial of service. This is due to the algorithmic complexity degradation from hash collisions, which can stall single-threaded runtimes such as Node.js. Applications that only store attacker input as values under fixed keys are not affected. There are no known exploits in the wild at this time.

A patch is available in Immutable.js version 5.1.8 that fixes the vulnerability by introducing a per-process seeded secondary hash to handle large collision buckets. Users should upgrade to version 5.1.8 or later. Until patched, mitigate by limiting request body size, restricting object key counts and lengths, and avoiding building Immutable Maps directly from untrusted object keys.