high · 7.5CVE-2026-59879Jul 21, 2026

CVE-2026-59879: Immutable.js List 32-bit Trie Overflow leading to Denial of Service

Shubham Kandhare
Security Engagement Manager, SecureLayer7

A crafted oversized index passed to an Immutable.js List method triggers an infinite loop or heap exhaustion that crashes or permanently hangs the Node.js process with no way to catch the error.

Packageimmutable
Ecosystemnpm
Affected< 4.3.9
Fixed in4.3.9

The problem

Immutable.js `List#set`, `List#setSize`, `List#setIn`, and `List#updateIn` pass any supplied index or size through `setListBounds()`, which uses JavaScript's bitwise left-shift (`1 << exp`) to drive a level-raising loop inside the 32-wide trie. JavaScript bitwise operations are signed 32-bit, so once the exponent reaches 31 the result goes negative and the loop condition never becomes false.

On an empty `List` this produces an uncatchable CPU-spin infinite loop. On a populated `List` of 32 or more elements every loop iteration allocates a new trie node, exhausting the heap until V8 aborts the process with `SIGABRT` (exit 134) or the kernel OOM-kills it (exit 137).

A single small HTTP request carrying a numeric path segment is enough. The index may arrive as a numeric string directly from a request body, URL parameter, or `setIn` key-path. A companion `setSize` bug silently wraps large values via `ToInt32`, corrupting the list size without throwing.

Proof of concept

A working proof-of-concept for CVE-2026-59879 in immutable, with the exact payload below.

javascript
// Scenario 1: OOM -> process abort (SIGABRT, exit 134) within ~2 s
// Requires a populated List of >= 32 elements (fromJS of any 64-element array)
import { fromJS, List } from 'immutable';

fromJS({ items: new Array(64).fill(0) })
  .setIn(['items', '1073741824'], 'x'); // index = 2**30, supplied as numeric string

// Scenario 2: Empty List -> hangs forever, uncatchable (try/catch never fires)
List().set(2 ** 30, 'x');

// Scenario 3: Silent size corruption via setSize
List([1, 2, 3]).setSize(2 ** 31);    // => size 0  (silently cleared)
List([1, 2, 3]).setSize(2 ** 32 + 5); // => size 5  (wraps to 5)

// Minimal remote trigger (43-byte JSON body applied as: state = state.setIn(path, value))
// {"path":["items","1073741824"],"value":"x"}
// Any index in [2**30, 2**31) works: 1073741824, 2000000000, etc.

The root cause is in the level-raising `while` loop inside `setListBounds()` in `src/List.js`. The loop condition is `newTailOffset >= 1 << (newLevel + SHIFT)`. JavaScript shift counts are taken mod 32, so when `newLevel + SHIFT` hits 31 the expression evaluates to `-2147483648` (negative), the condition stays permanently true, and the loop never exits.

On a populated List each iteration keeps a new `VNode([newRoot])` alive, so heap fills and the process aborts. On an empty List no allocation happens, producing a pure CPU spin.

The companion `setSize` corruption (CWE-190) is a separate but related path: `begin |= 0` and `end |= 0` apply `ToInt32`, silently wrapping `2**31` to `-2147483648` and `2**32 + 5` to `5`, yielding a wrong final size with no error.

The patch (commit `a1a1ee4` / `f0bc997`) adds a `validateListBoundsRequest()` call at the very top of `setListBounds()`, before any `| 0` coercion, that throws a catchable `RangeError` when the computed capacity exceeds `MAX_LIST_SIZE = 2**30`. It also replaces every `1 << exp` in the loop with a `levelCapacity(exp)` helper that uses the fast bitwise shift for `exp <= 30` and falls back to `2 ** exp` for deeper trees, eliminating the wrap-around entirely.

The fix

Upgrade to immutable 4.3.9 (v4 branch) or 5.1.8 (v5 branch). Both releases contain the same `setListBounds()` guard. If you cannot upgrade immediately, validate and clamp any externally supplied List index or `setIn`/`updateIn` key-path segment to be strictly less than `2**30` (1,073,741,824) before passing it to Immutable.

Running request handlers in a restartable worker and capping heap with `--max-old-space-size` limits blast radius but does not prevent the crash.

Reported by jdeniau.

References: [1][2][3][4][5][6]

Related research