Immutable.js CVE-2026-59880

Exploitation requires that attacker-controlled data be used to create keys in an Immutable.Map or Immutable.Set - specifically via one of the named ingestion paths Immutable.Map(obj), Immutable.fromJS(obj), state.merge(userObject), or mergeDeep - on a vulnerable version (<4.3.9 or <5.1.8), and the attacker must supply enough distinct keys sharing the same 32-bit hash to inflate a HashCollisionNode. What LIMITS exploitation: the application must actually route untrusted input into Map/Set keys (apps using only trusted or internal keys are not reachable), and the attacker benefits from knowing the hash algorithm to craft collisions; there is no authentication or user-interaction requirement (PR:N/UI:N), and impact is confined to availability (CPU/event-loop exhaustion) with no data exposure.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes an unauthenticated, low-complexity, network-reachable attack, and the impact metrics are honest: VC:N/VI:N with VA:H, i.e. pure availability loss with no confidentiality or integrity impact - consistent with a CPU-exhaustion DoS rather than the 'Information Disclosure' tag on the record, which appears mislabeled and should be disregarded. There is no CISA KEV listing and no POC referenced in the provided sources, so this is a real but not urgently-exploited issue; EPSS was not supplied, so likelihood cannot be quantified. Real-world risk is highly deployment-dependent: the flaw is only reachable when untrusted input is used to build Map/Set keys, so a service that funnels user JSON through fromJS/merge is meaningfully exposed, whereas an app that only stores trusted internal keys is not. Given the enormous install base of Immutable.js, aggregate exposure is significant even though any single deployment may not be reachable - the vector implies network reachability but exploitability depends on application data flow, which should be verified before prioritizing.

An attacker submits a large JSON object to an API endpoint whose handler calls Immutable.fromJS() or state.merge() on the request body; the object contains hundreds or thousands of keys deliberately chosen to collide on Immutable.js's 32-bit hash. Each insert and subsequent lookup triggers a linear scan of the growing collision bucket, so a single moderately-sized request pegs a CPU core and stalls the event loop, denying service to other users. No authentication or user interaction is required (PR:N/UI:N), and although no public POC is referenced, the hash-flooding technique is well understood.