CVE-2026-59879

What it actually does

CVE-2026-59879 is a denial-of-service flaw in Immutable.js List handling. Before Immutable.js 4.3.9 and 5.1.8, List#set, List#setSize, List#setIn, List#updateIn, and the functional set, setIn, and updateIn APIs mishandle indexes or sizes in the range 2^30 to 2^31 inside setListBounds in src/List.js. Depending on the List state and operation, attacker-controlled large indexes can cause an uncatchable infinite loop, unbounded memory allocation until the JavaScript process aborts, or silent size wrapping. In network-exposed applications that pass request-controlled values into these APIs, the impact is process-level availability loss without authentication or user interaction.

Why it matters to the business

Applications using vulnerable Immutable.js versions may be crashed or hung by specially crafted input, causing service outages, degraded availability, failed jobs, or container/process restarts. The issue is not listed in CISA KEV and has low EPSS at the time of assessment, but public exploitability is indicated and the CVSS availability impact is high, so internet-facing services, API backends, frontend rendering services, and queue workers that process untrusted indexes or sizes should be prioritized. Because Immutable.js is commonly pulled in through JavaScript dependency chains, exposure may exist indirectly through application frameworks or bundled code.

How an attack unfolds

An attacker looks for application functionality where a user-supplied array/list index, path component, pagination offset, size, or nested object path is passed into Immutable.js List mutation-style APIs such as set, setIn, updateIn, or setSize. The attacker then submits a value in the problematic large integer range, approximately 1073741824 through 2147483648, often as JSON, query parameters, form fields, or API path values. When vulnerable Immutable.js code evaluates the operation, setListBounds mishandles the boundary arithmetic. If the target List is empty, execution can enter an infinite loop that cannot be cleanly caught by application error handling; if the List is populated, the runtime may allocate memory without bound until the Node.js or browser JavaScript process aborts; setSize may wrap large values and corrupt expected logic. Repeating the request can keep worker processes, serverless functions, rendering services, or client-side sessions unavailable.

How to fix it

Upgrade Immutable.js to a fixed release: use 4.3.9 or later on the 4.x line, or 5.1.8 or later on the 5.x line. Regenerate lockfiles after dependency updates and ensure transitive dependency resolution does not retain vulnerable copies. If immediate upgrade is not possible, validate and clamp all user-controlled indexes, sizes, offsets, and path components before they reach Immutable.js List APIs; reject non-integer values, negative values where not explicitly required, and unusually large values, especially values greater than or equal to 1073741824. Add request size/rate limits and memory/process supervision to reduce blast radius, but treat these as compensating controls rather than a complete fix. For browser-distributed applications, rebuild and redeploy bundles so vulnerable library code is not shipped to clients.

How to confirm the fix worked

Confirm all package manifests and lockfiles resolve immutable to version 4.3.9 or later for 4.x deployments, or 5.1.8 or later for 5.x deployments. Run dependency audit tooling against package-lock.json, yarn.lock, pnpm-lock.yaml, and generated software bills of materials to identify duplicate or nested vulnerable versions. Search built JavaScript bundles for embedded Immutable.js versions if the package is browser-shipped. Add regression tests that exercise List#set, List#setSize, List#setIn, List#updateIn, set, setIn, and updateIn with boundary values around 1073741824 and 2147483647 and verify that the application rejects the input or completes safely without excessive CPU or memory growth. In staging, replay representative requests containing large indexes and confirm workers remain responsive and memory stable.

Typical attack path

1. Identify an application endpoint or client-side workflow that accepts user-controlled indexes, sizes, offsets, or nested path components.
2. Determine or infer that the application uses a vulnerable Immutable.js version before 4.3.9 or 5.1.8, directly or through bundled JavaScript dependencies.
3. Send crafted input containing an index or size in the 2^30 to 2^31 range, such as 1073741824, 1073741825, 2147483647, or similar boundary values.
4. Trigger vulnerable List#set, List#setSize, List#setIn, List#updateIn, set, setIn, or updateIn logic through the application workflow.
5. Cause the JavaScript runtime to hang in an infinite loop, allocate memory until abort, or silently wrap the requested size.
6. Repeat requests or trigger retries to sustain denial of service across application workers or dependent services.

How to detect it

To assess prior exploitation, review application, API gateway, WAF, CDN, reverse proxy, and load balancer logs for requests containing unusually large integer values in the 2^30 to 2^31 range, especially in fields named index, idx, size, length, offset, position, path, keyPath, page, limit, or nested JSON path arrays. Correlate those requests with Node.js process crashes, out-of-memory errors, container OOMKilled events, event-loop lag alerts, high CPU with no throughput, worker restarts, 502/503/504 spikes, or browser/client telemetry showing tab hangs. Inspect runtime logs for fatal JavaScript heap exhaustion, allocation failures, process aborts, and supervisor restart messages near suspicious requests. For frontend applications, use RUM/crash telemetry to look for client hangs or memory failures following user inputs containing boundary-size numbers. Absence of a unique exploit signature means detection should focus on boundary numeric inputs plus immediate availability symptoms.

• 1073741824
• 1073741825
• 1073741826
• 2147483647
• 2147483648
• index=1073741824
• index=2147483647
• size=1073741824
• size=2147483647
• length=1073741824
• offset=1073741824
• position=1073741824
• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed
• Allocation failed - JavaScript heap out of memory
• OOMKilled
• heap out of memory
• setListBounds
• List#set
• List#setSize
• List#setIn
• List#updateIn

What your security team should do

• Inventory all applications and packages using the immutable npm package, including transitive dependencies and frontend bundles.
• Prioritize remediation for internet-facing Node.js services, API gateways, SSR/rendering systems, queue consumers, and browser bundles that process untrusted indexes, offsets, paths, or sizes.
• Upgrade to immutable 4.3.9+ or 5.1.8+ and redeploy rebuilt artifacts; verify lockfiles do not retain vulnerable duplicate versions.
• Implement application-level input validation to reject extreme integer indexes and sizes before calling Immutable.js APIs.
• Create monitoring for sudden JavaScript process CPU saturation, memory exhaustion, out-of-memory kills, event-loop stalls, container restarts, and repeated requests containing boundary values near 2^30 to 2^31.
• Review recent application logs for suspicious large numeric values in request bodies, query strings, and path parameters, especially values around 1073741824 and 2147483647.
• Because public exploit code is available, treat confirmed exposure in externally reachable services as urgent even though the vulnerability is not currently in CISA KEV.