CVE-2026-59880

What it actually does

This vulnerability is an algorithmic complexity denial-of-service issue in Immutable.js. Before versions 4.3.9 and 5.1.8, Immutable.Map and Immutable.Set store keys with the same 32-bit hash in a HashCollisionNode bucket and scan that bucket linearly. If an attacker can supply many object keys or values that are inserted into Immutable.Map, Immutable.Set, Immutable.fromJS, state.merge(userObject), mergeDeep, or similar code paths, they can force excessive CPU consumption during insertions and lookups. The result is degraded application responsiveness or process-level denial of service without requiring authentication or user interaction when the vulnerable parsing or merge path is exposed over the network.

Why it matters to the business

Applications that accept attacker-controlled structured input and convert or merge it into Immutable.js collections may become slow or unavailable when processing crafted requests. This can disrupt APIs, web applications, server-side rendering, background workers, or state-management services that depend on Immutable.js. Although the issue does not directly expose or modify data, it can cause service degradation, increased infrastructure costs from CPU exhaustion, failed transactions, and potential outage conditions. The CVSS availability impact is high, exploit code is reported as available, and the issue has been public for over a month, so internet-facing services using affected versions should be prioritized even though it is not currently listed in CISA KEV and has a low EPSS score.

How an attack unfolds

An attacker first identifies an application endpoint or processing path that accepts JSON, form data, query parameters, GraphQL variables, WebSocket messages, or other structured input and passes attacker-controlled keys into Immutable.js objects. They then craft a payload containing many keys that produce the same 32-bit Immutable.js hash value. When the application calls Immutable.Map(obj), Immutable.fromJS(obj), merge, mergeDeep, or inserts those keys into Immutable.Map or Immutable.Set, the library places the colliding keys into a single HashCollisionNode. Because affected versions linearly scan that collision bucket for insertions and lookups, processing cost grows disproportionately as the number of colliding keys increases. Repeated or concurrent requests can saturate CPU, delay the event loop in Node.js applications, exhaust worker capacity, and cause timeouts or service unavailability.

How to fix it

Upgrade Immutable.js to a fixed release: use version 4.3.9 or later on the 4.x branch, or version 5.1.8 or later on the 5.x branch. Because this vulnerability may be introduced transitively through JavaScript package dependencies, review lockfiles and dependency trees, then rebuild and redeploy affected applications after updating. If immediate upgrade is not possible, reduce exposure by enforcing request body size limits, limiting object key counts and nesting depth, rejecting unusually large or deeply nested JSON objects, applying per-client rate limits, setting server-side request timeouts, and avoiding direct merges of untrusted objects into Immutable.js collections. Prefer schema validation that allowlists expected keys before invoking Immutable.Map, Immutable.fromJS, merge, or mergeDeep on user-controlled data.

How to confirm the fix worked

Confirm that no deployed package or bundled artifact contains Immutable.js versions earlier than 4.3.9 on the 4.x line or earlier than 5.1.8 on the 5.x line. Check package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls immutable, yarn why immutable, or pnpm why immutable, and verify the runtime bundle if dependencies are vendored or bundled into frontend/server assets. Run regression tests against endpoints that process large JSON objects to confirm they enforce key-count, size, and depth limits and no longer show disproportionate CPU growth. In production, validate that CPU utilization, request latency, event-loop delay, timeout rates, and 5xx responses remain stable when malformed or oversized structured input is rejected.

Typical attack path

1. Find an application endpoint that accepts attacker-controlled structured input.
2. Determine that the application or one of its dependencies uses Immutable.js before 4.3.9 or 5.1.8.
3. Craft input containing many keys that collide under Immutable.js 32-bit hashing.
4. Send the crafted payload to a code path that constructs or merges Immutable.Map, Immutable.Set, Immutable.fromJS, state.merge, or mergeDeep data.
5. Trigger linear scans inside HashCollisionNode collision buckets during insertion or lookup.
6. Repeat requests or increase payload size to consume CPU and degrade or deny service.

How to detect it

Look for evidence of denial-of-service attempts against endpoints that accept structured input and are backed by applications using vulnerable Immutable.js versions. Useful log sources include web server and reverse proxy access logs, application request logs, API gateway logs, WAF logs, Node.js process logs, APM traces, container metrics, CPU metrics, event-loop delay metrics, and error logs. Focus on time windows with sudden CPU saturation, increased request latency, event-loop lag, request timeouts, worker restarts, out-of-memory-adjacent symptoms caused by stalled processing, or elevated 5xx/499/504 responses. Review request metadata for unusually large JSON bodies, high object key counts, deeply nested objects, repeated requests to the same endpoint from a small set of IPs, and requests that complete slowly despite small response sizes. If request bodies are safely logged or captured under an approved process, inspect for large numbers of unusual, randomly generated, or similarly patterned object keys submitted to JSON, GraphQL, state synchronization, or merge endpoints. There are no universal network indicators because exploit payloads depend on crafted hash-colliding keys and application-specific routes.

• immutable@<4.3.9
• immutable@<5.1.8
• HashCollisionNode
• Immutable.Map(
• Immutable.fromJS(
• mergeDeep(
• state.merge(
• npm ls immutable
• yarn why immutable
• pnpm why immutable
• package-lock.json
• yarn.lock
• pnpm-lock.yaml
• HTTP 413
• HTTP 429
• HTTP 499
• HTTP 504
• PayloadTooLargeError
• request entity too large
• event loop delay
• ETIMEDOUT
• ECONNRESET

What your security team should do

• Inventory applications and services that use the immutable npm package directly or transitively.
• Prioritize internet-facing APIs, Node.js services, server-side rendering paths, and applications that merge user-supplied JSON or state objects.
• Upgrade Immutable.js to 4.3.9 or later, or 5.1.8 or later, and redeploy rebuilt artifacts.
• Add schema validation, request size limits, object key-count limits, nesting-depth limits, rate limits, and request timeouts for endpoints accepting structured input.
• Search dependency lockfiles and software composition analysis results for vulnerable immutable versions and track remediation to closure.
• Monitor for abnormal CPU spikes, event-loop lag, request timeouts, repeated large payloads, and high rates of 400/413/429/5xx responses from endpoints that parse JSON or merge state.
• Because exploit code is available, treat unexplained CPU exhaustion on affected services as potentially malicious until logs and payload patterns are reviewed.