Go to packages list

immutable

Ecosystem: npm

Downloads:

Vulnerabilities from the last (months)
  • 0CriticalAffects 0 versions
  • 3HighAffects 9 versions
  • 0MediumAffects 0 versions
  • 0ModerateAffects 0 versions
  • 0LowAffects 0 versions
Severity distribution (all time)
3vulnerabilities
  • Critical0 (0.0%)
  • High3 (100.0%)
  • Medium0 (0.0%)
  • Moderate0 (0.0%)
  • Low0 (0.0%)

Monthly breakdown

  • Critical
  • High
  • Medium
  • Moderate
  • Low
  • 2 vulnerabilities
    • Critical: 0
    • High: 2
    • Medium: 0
    • Moderate: 0
    • Low: 0
  • 1 vulnerabilities
    • Critical: 0
    • High: 1
    • Medium: 0
    • Moderate: 0
    • Low: 0

Vulnerabilities (3)

Known vulnerabilities affecting immutable, based on data from OSV.

Vulnerabilities affecting immutable
IDSeveritySummaryAffected versionsPublishedSource
GHSA-v56q-mh7h-f735HighImmutable.js `List` 32-bit trie overflow → unrecoverable DoS## Summary `List#set`, `List#setSize`, `List#setIn`, `List#updateIn` (and the functional `set` / `setIn` / `updateIn`) mishandle an index or size in the range `[2 ** 30, 2 ** 31)`: - On an **empty** `List` the operation enters an **uncatchable infinite loop** (a tight CPU spin; a surrounding `try/catch` never regains control). Only killing the worker recovers it. - On a **populated** `List` (≥ 32 elements — i.e. any array of ≥ 32 items turned into a `List` by `fromJS`) the loop allocates without bound → heap exhaustion → the **process aborts** (`SIGABRT`, exit `134`, or kernel OOM-kill `137`
  • >= 4.0.0-rc.1, < 4.3.9
  • >= 5.0.0-beta.1, < 5.1.8
  • < 3.8.4
GitHub (opens in a new tab)
GHSA-xvcm-6775-5m9rHighImmutable: Hash-collision algorithmic complexity denial of service in Immutable.Map/Set## Summary `Immutable.Map` and `Immutable.Set` keep keys that share the same 32-bit hash in a collision bucket that is scanned linearly. The string hash is public and deterministic, so an attacker who controls the **keys** inserted into a Map can craft many keys that all collide, degrading insertion and lookup from amortized O(1) to O(n) per operation — and O(n²) to build or read the whole set. A small, attacker-shaped payload can therefore consume disproportionate CPU and, on a single-threaded runtime such as Node.js, stall the event loop and deny service. ## Details The string hash uses t
  • >= 4.0.0-beta.1, < 4.3.9
  • >= 5.0.0-beta.1, < 5.1.8
  • < 3.8.4
GitHub (opens in a new tab)
GHSA-wf6x-7x77-mvgwHighImmutable is vulnerable to Prototype Pollution## Impact _What kind of vulnerability is it? Who is impacted?_ A Prototype Pollution is possible in immutable via the mergeDeep(), mergeDeepWith(), merge(), Map.toJS(), and Map.toObject() APIs. ## Affected APIs | API | Notes | | --------------------------------------- | ----------------------------------------------------------- | | `mergeDeep(target, source)` | Iterates source keys via `ObjectSeq`, assigns `merged[key]` | | `mergeDeepWith(merger, target, source)` | Same code path
  • >= 4.0.0-rc.1, < 4.3.8
  • >= 5.0.0, < 5.1.5
  • < 3.8.3
GitHub (opens in a new tab)
  • GHSA-v56q-mh7h-f735High
    Immutable.js `List` 32-bit trie overflow → unrecoverable DoS
    • >= 4.0.0-rc.1, < 4.3.9
    • >= 5.0.0-beta.1, < 5.1.8
    • +1 more
    GitHub (opens in a new tab)
    Affected versions:
    • >= 4.0.0-rc.1, < 4.3.9
    • >= 5.0.0-beta.1, < 5.1.8
    • < 3.8.4

    ## Summary `List#set`, `List#setSize`, `List#setIn`, `List#updateIn` (and the functional `set` / `setIn` / `updateIn`) mishandle an index or size in the range `[2 ** 30, 2 ** 31)`: - On an **empty** `List` the operation enters an **uncatchable infinite loop** (a tight CPU spin; a surrounding `try/catch` never regains control). Only killing the worker recovers it. - On a **populated** `List` (≥ 32 elements — i.e. any array of ≥ 32 items turned into a `List` by `fromJS`) the loop allocates without bound → heap exhaustion → the **process aborts** (`SIGABRT`, exit `134`, or kernel OOM-kill `137`

    CVE: CVE-2026-59879

  • GHSA-xvcm-6775-5m9rHigh
    Immutable: Hash-collision algorithmic complexity denial of service in Immutable.Map/Set
    • >= 4.0.0-beta.1, < 4.3.9
    • >= 5.0.0-beta.1, < 5.1.8
    • +1 more
    GitHub (opens in a new tab)
    Affected versions:
    • >= 4.0.0-beta.1, < 4.3.9
    • >= 5.0.0-beta.1, < 5.1.8
    • < 3.8.4

    ## Summary `Immutable.Map` and `Immutable.Set` keep keys that share the same 32-bit hash in a collision bucket that is scanned linearly. The string hash is public and deterministic, so an attacker who controls the **keys** inserted into a Map can craft many keys that all collide, degrading insertion and lookup from amortized O(1) to O(n) per operation — and O(n²) to build or read the whole set. A small, attacker-shaped payload can therefore consume disproportionate CPU and, on a single-threaded runtime such as Node.js, stall the event loop and deny service. ## Details The string hash uses t

    CVE: CVE-2026-59880

  • GHSA-wf6x-7x77-mvgwHigh
    Immutable is vulnerable to Prototype Pollution
    • >= 4.0.0-rc.1, < 4.3.8
    • >= 5.0.0, < 5.1.5
    • +1 more
    GitHub (opens in a new tab)
    Affected versions:
    • >= 4.0.0-rc.1, < 4.3.8
    • >= 5.0.0, < 5.1.5
    • < 3.8.3

    ## Impact _What kind of vulnerability is it? Who is impacted?_ A Prototype Pollution is possible in immutable via the mergeDeep(), mergeDeepWith(), merge(), Map.toJS(), and Map.toObject() APIs. ## Affected APIs | API | Notes | | --------------------------------------- | ----------------------------------------------------------- | | `mergeDeep(target, source)` | Iterates source keys via `ObjectSeq`, assigns `merged[key]` | | `mergeDeepWith(merger, target, source)` | Same code path

    CVE: CVE-2026-29063

Showing 1-3 of 3 vulnerabilities