Common Weakness Enumeration

CWE-1284

Allowed

Improper Validation of Specified Quantity in Input

Abstraction: Base · Status: Incomplete

The product receives input that is expected to specify a quantity (such as size or length), but it does not validate or incorrectly validates that the quantity has the required properties.

659 vulnerabilities reference this CWE, most recent first.

GHSA-RRGF-J5XJ-H9HC

Vulnerability from github – Published: 2026-06-17 18:35 – Updated: 2026-06-17 18:35
VLAI
Details

sppp_pap_input in sys/net/if_spppsubr.c in OpenBSD before 076e2b1 allows authentication bypass via certain zero values for lengths.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-55706"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-17T13:20:52Z",
    "severity": "MODERATE"
  },
  "details": "sppp_pap_input in sys/net/if_spppsubr.c in OpenBSD before 076e2b1 allows authentication bypass via certain zero values for lengths.",
  "id": "GHSA-rrgf-j5xj-h9hc",
  "modified": "2026-06-17T18:35:52Z",
  "published": "2026-06-17T18:35:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55706"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbsd/src/commit/076e2b1c1fc4ac0883a72d3544131ad5cee7adf8"
    },
    {
      "type": "WEB",
      "url": "https://blog.argus-systems.ai/blog/openbsd-pap-27-year-auth-bypass.html"
    },
    {
      "type": "WEB",
      "url": "https://blog.argus-systems.ai/blog/poc-001-pap-bypass.py"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2026/06/16/9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RRW4-C99G-5P92

Vulnerability from github – Published: 2026-10-14 18:32 – Updated: 2026-10-14 18:32
VLAI
Details

A Improper Validation of Specified Quantity in Input vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS Evolved on PTX Series allows an unauthenticated IS-IS peer to cause a denial of service.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-101985"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-14T17:17:50Z",
    "severity": "HIGH"
  },
  "details": "A Improper Validation of Specified Quantity in Input vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS Evolved on PTX Series allows an unauthenticated IS-IS peer to cause a denial of service.",
  "id": "GHSA-rrw4-c99g-5p92",
  "modified": "2026-10-14T18:32:22Z",
  "published": "2026-10-14T18:32:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101985"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA112250"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-RWV9-WGMX-5VQ4

Vulnerability from github – Published: 2026-02-25 21:31 – Updated: 2026-02-25 21:31
VLAI
Details

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 12.2 before 18.7.5, 18.8 before 18.8.5, and 18.9 before 18.9.1 that could have allowed an unauthenticated user to cause denial of service by sending specially crafted files to the container registry event endpoint under certain conditions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-14511"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-25T21:16:30Z",
    "severity": "HIGH"
  },
  "details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 12.2 before 18.7.5, 18.8 before 18.8.5, and 18.9 before 18.9.1 that could have allowed an unauthenticated user to cause denial of service by sending specially crafted files to the container registry event endpoint under certain conditions.",
  "id": "GHSA-rwv9-wgmx-5vq4",
  "modified": "2026-02-25T21:31:19Z",
  "published": "2026-02-25T21:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14511"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3452200"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2026/02/25/patch-release-gitlab-18-9-1-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/583717"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V2CV-5HX2-P7W9

Vulnerability from github – Published: 2026-04-14 18:30 – Updated: 2026-04-22 15:31
VLAI
Details

CWE-1284 Improper Validation of Specified Quantity in Input vulnerability exists that could cause Event and Data Log truncation impacting log integrity when a Web Admin user alters the POST /logsettings request payload.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-2403"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-14T16:16:38Z",
    "severity": "MODERATE"
  },
  "details": "CWE-1284 Improper Validation of Specified Quantity in Input vulnerability exists that could cause Event and Data Log truncation impacting log integrity when a Web Admin user alters the POST /logsettings request payload.",
  "id": "GHSA-v2cv-5hx2-p7w9",
  "modified": "2026-04-22T15:31:32Z",
  "published": "2026-04-14T18:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2403"
    },
    {
      "type": "WEB",
      "url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2026-104-01\u0026p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2026-104-01.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-V3CQ-93XF-4P42

Vulnerability from github – Published: 2026-07-22 15:31 – Updated: 2026-07-22 15:31
VLAI
Details

In NLnet Labs Unbound 1.22.0 up to and including 1.25.1, when downstream DNS-over-QUIC (DoQ) is enabled, the first two bidirectional streams on a new QUIC connection (stream_id 0 and 4) bypass the per-stream 'quic-size' gate entirely, and large input buffers are allocated later, after only the 2-byte length prefix has been received from the initial streams. As a result, a remote client can make Unbound exceed the configured 'quic-size' limit with low-cost input. Using only one connection and two streams, each sending a declared 65535-byte length prefix and then holding the streams open, a client can already trivially make Unbound roughly allocate double that amount. This is a remote availability issue / memory-accounting bypass in the downstream DoQ implementation that leads to denial of service for new DoQ clients. This vulnerability needs Unbound to be compiled with DoQ support ('--with-libngtcp2') and the 'quic-port' to be configured for the listening interfaces.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-32665"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-22T14:17:18Z",
    "severity": "HIGH"
  },
  "details": "In NLnet Labs Unbound 1.22.0 up to and including 1.25.1, when downstream DNS-over-QUIC (DoQ) is enabled, the first two bidirectional streams on a new QUIC connection (stream_id 0 and 4) bypass the per-stream \u0027quic-size\u0027 gate entirely, and large input buffers are allocated later, after only the 2-byte length prefix has been received from the initial streams. As a result, a remote client can make Unbound exceed the configured \u0027quic-size\u0027 limit with low-cost input. Using only one connection and two streams, each sending a declared 65535-byte length prefix and then holding the streams open, a client can already trivially make Unbound roughly allocate double that amount. This is a remote availability issue / memory-accounting bypass in the downstream DoQ implementation that leads to denial of service for new DoQ clients. This vulnerability needs Unbound to be compiled with DoQ support (\u0027--with-libngtcp2\u0027) and the \u0027quic-port\u0027 to be configured for the listening interfaces.",
  "id": "GHSA-v3cq-93xf-4p42",
  "modified": "2026-07-22T15:31:24Z",
  "published": "2026-07-22T15:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32665"
    },
    {
      "type": "WEB",
      "url": "https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-32665.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V3X4-26XJ-QRVG

Vulnerability from github – Published: 2025-05-07 18:30 – Updated: 2025-05-07 18:30
VLAI
Details

A vulnerability in the implementation of the Simple Network Management Protocol Version 3 (SNMPv3) feature of Cisco IOS Software and Cisco IOS XE Software could allow an authenticated, remote attacker to poll an affected device using SNMP, even if the device is configured to deny SNMP traffic from an unauthorized source or the SNMPv3 username is removed from the configuration.

This vulnerability exists because of the way that the SNMPv3 configuration is stored in the Cisco IOS Software and Cisco IOS XE Software startup configuration. An attacker could exploit this vulnerability by polling an affected device from a source address that should have been denied. A successful exploit could allow the attacker to perform SNMP operations from a source that should be denied. Note: The attacker has no control of the SNMPv3 configuration. To exploit this vulnerability, the attacker must have valid SNMPv3 user credentials. For more information, see the section of this advisory.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-20151"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-07T18:15:37Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the implementation of the Simple Network Management Protocol Version 3 (SNMPv3) feature of Cisco IOS Software and Cisco IOS XE Software could allow an authenticated, remote attacker to poll an affected device using SNMP, even if the device is configured to deny SNMP traffic from an unauthorized source or the SNMPv3 username is removed from the configuration.\n\nThis vulnerability exists because of the way that the SNMPv3 configuration is stored in the Cisco IOS Software and Cisco IOS XE Software startup configuration. An attacker could exploit this vulnerability by polling an affected device from a source address that should have been denied. A successful exploit could allow the attacker to perform SNMP operations from a source that should be denied.\nNote: The attacker has no control of the SNMPv3 configuration. To exploit this vulnerability, the attacker must have valid SNMPv3 user credentials.\nFor more information, see the  section of this advisory.",
  "id": "GHSA-v3x4-26xj-qrvg",
  "modified": "2025-05-07T18:30:48Z",
  "published": "2025-05-07T18:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20151"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snmpv3-qKEYvzsy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V55P-HQX9-66GF

Vulnerability from github – Published: 2024-04-23 09:30 – Updated: 2024-04-23 09:30
VLAI
Details

A key used in logging.json does not follow the least privilege principle by default and is exposed to local users in the Rapid7 Platform. This allows an attacker with local access to a machine with the logging.json file to use that key to authenticate to the platform with high privileges. This was fixed in the Rapid7 platform starting 3 April 2024 via the introduction of a restricted role and the removal of automatic API key generation on installation of an agent.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-3185"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-23T09:15:07Z",
    "severity": "MODERATE"
  },
  "details": " A key used in logging.json does not follow the least privilege principle by default and is exposed to local users in the Rapid7 Platform.  This allows an attacker with local access to a machine with the logging.json file to use that key to authenticate to the platform with high privileges.  This was fixed in the Rapid7 platform starting 3 April 2024 via the introduction of a restricted role and the removal of automatic API key generation on installation of an agent.",
  "id": "GHSA-v55p-hqx9-66gf",
  "modified": "2024-04-23T09:30:46Z",
  "published": "2024-04-23T09:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3185"
    },
    {
      "type": "WEB",
      "url": "https://docs.rapid7.com/insightidr/configure-the-insight-agent-to-send-logs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V56Q-MH7H-F735

Vulnerability from github – Published: 2026-07-21 18:36 – Updated: 2026-09-16 18:47
VLAI
Summary
Immutable.js `List` 32-bit trie overflow → unrecoverable DoS
Details

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). A real crash, not a recoverable error.

The index may be a numeric string, so it can come straight from a request body, URL, or key-path. A single small unauthenticated request is enough.

There is also a companion silent data-corruption issue in setSize:

List([1, 2, 3]).setSize(2 ** 31); // before fix => size 0  (silently cleared)
List([1, 2, 3]).setSize(2 ** 32 + 5); // before fix => size 5  (huge value wraps to 5)

Impact

Availability only. A reachable configuration is any endpoint that routes untrusted input into a List index or a setIn/updateIn key-path — which the extremely common state = fromJS(body); state.setIn(userPath, value) pattern does (config stores, document/collection editors, redux-immutable reducers, JSON-Patch endpoints, etc.).

No confidentiality or integrity impact, no RCE. The companion setSize bug can silently corrupt application state (wrong size) without crashing.

Reproduction (immutable 5.1.7)

import { fromJS, List } from 'immutable';

// 1) Populated List: OOM -> process abort (SIGABRT, exit 134) within ~2s
fromJS({ items: new Array(64).fill(0) }).setIn(['items', '1073741824'], 'x');

// 2) Empty List: hangs forever, uncatchable
List().set(2 ** 30, 'x');

// 3) Silent truncation
List([1, 2, 3]).setSize(2 ** 31); // => size 0
List([1, 2, 3]).setSize(2 ** 32 + 5); // => size 5

A remote 43-byte HTTP request ({"path":["items","1073741824"],"value":"x"}) is sufficient to abort a worker that applies it via state = state.setIn(path, value).

Any index in [2 ** 30, 2 ** 31) works (1073741824, 2000000000, …). An index in [2 ** 31, 2 ** 32) does not crash — it silently wraps (clearing the List) via the same root cause.

Root cause

List stores its values in a 32-wide trie (SHIFT = 5, so each level addresses 5 more bits) and uses signed 32-bit bitwise arithmetic throughout setListBounds() (src/List.js):

  1. Infinite loop (the hang / OOM). The level-raising loop
while (newTailOffset >= 1 << (newLevel + SHIFT)) {
  newRoot = new VNode(
    newRoot && newRoot.array.length ? [newRoot] : [],
    owner
  );
  newLevel += SHIFT;
}

relies on 1 << (newLevel + SHIFT). A JavaScript shift count is taken mod 32, so once newLevel + SHIFT reaches 31 the term goes negative (1 << 31 === -2147483648) and at 32 wraps to 1 (1 << 35 === 8). The comparison then stays true forever and the loop never terminates. On a populated List, each iteration retains a new VNode ([newRoot]), so the heap fills and V8 aborts; on an empty List it spins on CPU without allocating.

  1. Silent wraparound (the setSize corruption). The begin |= 0 / end |= 0 coercion (ToInt32) silently wraps large finite values ((2 ** 31) | 0 === -2147483648, (2 ** 32 + 5) | 0 === 5), producing a wrong resulting size instead of an error.

The threshold is 2 ** 30: that is the largest size for which 1 << (newLevel + SHIFT) stays a valid positive 32-bit integer throughout the loops (newLevel + SHIFT stays ≤ 30).

Remediation

The fix is contained to setListBounds() in src/List.js:

  1. Validate up front, before the lossy | 0 coercion. Compute the intended origin and capacity in full precision and throw a clear, catchable RangeError when they exceed the addressable range (MAX_LIST_SIZE = 2 ** 30). Infinity/NaN are left to the existing | 0 → 0 behaviour (so setSize(Infinity) stays 0 and slice(0, Infinity) still means "to the end").

  2. Stop the shift from wrapping. Replace 1 << exp in the level-raising loops with a helper that uses the cheap bitwise shift while it is exact (exp ≤ 30, the common path including every push/setSize/slice) and falls back to the non-wrapping 2 ** exp only for the rare deep trees reached when a negative origin (unshift / negative index) is normalized to a large positive capacity (exp can reach 35 there, where 1 << 35 would wrap to 8).

This turns every hang, the misleading "Maximum call stack size exceeded", the OOM/SIGABRT, and the silent setSize truncation into one descriptive RangeError, preserves all behaviour for sizes < 2 ** 30, and keeps the hot push path on the fast bitwise shift (the 2 ** exp branch is never reached by non-negative operations).

Is the new limit a breaking change?

No working code is affected. A List could never actually hold ≥ 2 ** 30 values before — the attempt hung, crashed, or silently corrupted the size. The limit was already implicit in the 32-bit trie; the fix only makes it explicit and catchable, mirroring native JS arrays (new Array(2 ** 32) → RangeError: Invalid array length). The single observable behaviour change is that setSize(hugeValue), which used to return a silently wrong size, now throws. 2 ** 30 ≈ 1.07 billion entries (~8 GB of pointers alone), far beyond any practical use.

Mitigations (for users who cannot upgrade immediately)

  • Validate/clamp any externally supplied List index or setIn/updateIn key-path segment against a sane maximum before passing it to immutable.
  • Reject numeric path segments ≥ 2 ** 30.
  • Run request handling in a worker that can be restarted, and cap the heap (--max-old-space-size) so an abort is contained.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "immutable"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-rc.1"
            },
            {
              "fixed": "4.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "immutable"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-beta.1"
            },
            {
              "fixed": "5.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "immutable"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.8.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59879"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-190",
      "CWE-400",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T18:36:27Z",
    "nvd_published_at": "2026-07-08T17:17:26Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`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)`:\n\n- 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.\n- On a **populated** `List` (\u2265 32 elements \u2014 i.e. any array of \u2265 32 items turned into a `List` by `fromJS`) the loop allocates without bound \u2192 heap exhaustion \u2192 the **process aborts** (`SIGABRT`, exit `134`, or kernel OOM-kill `137`). A real crash, not a recoverable error.\n\nThe index may be a **numeric string**, so it can come straight from a request body, URL, or key-path. A single small unauthenticated request is enough.\n\nThere is also a companion **silent data-corruption** issue in `setSize`:\n\n```js\nList([1, 2, 3]).setSize(2 ** 31); // before fix =\u003e size 0  (silently cleared)\nList([1, 2, 3]).setSize(2 ** 32 + 5); // before fix =\u003e size 5  (huge value wraps to 5)\n```\n\n## Impact\n\nAvailability only. A reachable configuration is any endpoint that routes untrusted input into a `List` index or a `setIn`/`updateIn` key-path \u2014 which the extremely common `state = fromJS(body); state.setIn(userPath, value)` pattern does (config stores, document/collection editors, redux-immutable reducers, JSON-Patch endpoints, etc.).\n\nNo confidentiality or integrity impact, no RCE. The companion `setSize` bug can silently corrupt application state (wrong size) without crashing.\n\n## Reproduction (immutable 5.1.7)\n\n```ts\nimport { fromJS, List } from \u0027immutable\u0027;\n\n// 1) Populated List: OOM -\u003e process abort (SIGABRT, exit 134) within ~2s\nfromJS({ items: new Array(64).fill(0) }).setIn([\u0027items\u0027, \u00271073741824\u0027], \u0027x\u0027);\n\n// 2) Empty List: hangs forever, uncatchable\nList().set(2 ** 30, \u0027x\u0027);\n\n// 3) Silent truncation\nList([1, 2, 3]).setSize(2 ** 31); // =\u003e size 0\nList([1, 2, 3]).setSize(2 ** 32 + 5); // =\u003e size 5\n```\n\nA remote 43-byte HTTP request (`{\"path\":[\"items\",\"1073741824\"],\"value\":\"x\"}`) is sufficient to abort a worker that applies it via `state = state.setIn(path, value)`.\n\nAny index in `[2 ** 30, 2 ** 31)` works (`1073741824`, `2000000000`, \u2026). An index in `[2 ** 31, 2 ** 32)` does not crash \u2014 it silently wraps (clearing the List) via the same root cause.\n\n## Root cause\n\n`List` stores its values in a 32-wide trie (`SHIFT = 5`, so each level addresses 5 more bits) and uses **signed 32-bit bitwise arithmetic** throughout `setListBounds()` (`src/List.js`):\n\n1. **Infinite loop (the hang / OOM).** The level-raising loop\n\n```js\nwhile (newTailOffset \u003e= 1 \u003c\u003c (newLevel + SHIFT)) {\n  newRoot = new VNode(\n    newRoot \u0026\u0026 newRoot.array.length ? [newRoot] : [],\n    owner\n  );\n  newLevel += SHIFT;\n}\n```\n\nrelies on `1 \u003c\u003c (newLevel + SHIFT)`. A JavaScript shift count is taken **mod 32**, so once `newLevel + SHIFT` reaches `31` the term goes **negative** (`1 \u003c\u003c 31 === -2147483648`) and at `32` wraps to `1` (`1 \u003c\u003c 35 === 8`). The comparison then stays `true` forever and the loop never terminates. On a populated `List`, each iteration retains a new `VNode` (`[newRoot]`), so the heap fills and V8 aborts; on an empty `List` it spins on CPU without allocating.\n\n2. **Silent wraparound (the `setSize` corruption).** The `begin |= 0` / `end |= 0` coercion (`ToInt32`) silently wraps large finite values (`(2 ** 31) | 0 === -2147483648`, `(2 ** 32 + 5) | 0 === 5`), producing a wrong resulting size instead of an error.\n\nThe threshold is `2 ** 30`: that is the largest size for which `1 \u003c\u003c (newLevel + SHIFT)` stays a valid positive 32-bit integer throughout the loops (`newLevel + SHIFT` stays \u2264 30).\n\n## Remediation\n\nThe fix is contained to `setListBounds()` in `src/List.js`:\n\n1. **Validate up front, before the lossy `| 0` coercion.** Compute the intended origin and capacity in full precision and throw a clear, catchable `RangeError` when they exceed the addressable range (`MAX_LIST_SIZE = 2 ** 30`). `Infinity`/`NaN` are left to the existing `| 0 \u2192 0` behaviour (so `setSize(Infinity)` stays `0` and `slice(0, Infinity)` still means \"to the end\").\n\n2. **Stop the shift from wrapping.** Replace `1 \u003c\u003c exp` in the level-raising loops with a helper that uses the cheap bitwise shift while it is exact (`exp \u2264 30`, the common path including every `push`/`setSize`/`slice`) and falls back to the non-wrapping `2 ** exp` only for the rare deep trees reached when a negative origin (`unshift` / negative index) is normalized to a large positive capacity (`exp` can reach 35 there, where `1 \u003c\u003c 35` would wrap to 8).\n\nThis turns every hang, the misleading `\"Maximum call stack size exceeded\"`, the OOM/`SIGABRT`, and the silent `setSize` truncation into one descriptive `RangeError`, preserves all behaviour for sizes `\u003c 2 ** 30`, and keeps the hot `push` path on the fast bitwise shift (the `2 ** exp` branch is never reached by non-negative operations).\n\n### Is the new limit a breaking change?\n\nNo working code is affected. A `List` could never actually hold `\u2265 2 ** 30` values before \u2014 the attempt hung, crashed, or silently corrupted the size. The limit was already implicit in the 32-bit trie; the fix only makes it explicit and catchable, mirroring native JS arrays (`new Array(2 ** 32)` \u2192 `RangeError: Invalid array length`). The single observable behaviour change is that `setSize(hugeValue)`, which used to return a silently wrong size, now throws. `2 ** 30` \u2248 1.07 billion entries (~8 GB of pointers alone), far beyond any practical use.\n\n## Mitigations (for users who cannot upgrade immediately)\n\n- Validate/clamp any externally supplied `List` index or `setIn`/`updateIn` key-path segment against a sane maximum before passing it to immutable.\n- Reject numeric path segments `\u2265 2 ** 30`.\n- Run request handling in a worker that can be restarted, and cap the heap (`--max-old-space-size`) so an abort is contained.",
  "id": "GHSA-v56q-mh7h-f735",
  "modified": "2026-09-16T18:47:10Z",
  "published": "2026-07-21T18:36:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/immutable-js/immutable-js/security/advisories/GHSA-v56q-mh7h-f735"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59879"
    },
    {
      "type": "WEB",
      "url": "https://github.com/immutable-js/immutable-js/commit/a1a1ee412dcaa380ab325196283d06594ffe4b84"
    },
    {
      "type": "WEB",
      "url": "https://github.com/immutable-js/immutable-js/commit/f0bc997d8eb9886aff2236635aa210a95a04304a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/immutable-js/immutable-js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/immutable-js/immutable-js/releases/tag/v3.8.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/immutable-js/immutable-js/releases/tag/v4.3.9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/immutable-js/immutable-js/releases/tag/v5.1.8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Immutable.js `List` 32-bit trie overflow \u2192 unrecoverable DoS"
}

GHSA-V648-FVF7-JRG2

Vulnerability from github – Published: 2026-08-27 21:31 – Updated: 2026-08-27 21:31
VLAI
Details

DeadLetterPublishingRecovererFactory reads the retry_topic-original-timestamp header from an inbound ConsumerRecord and passes its raw bytes directly to new BigInteger(header.value()) with no length or format validation. Spring for Apache Kafka 4.1.0 Spring for Apache Kafka 4.0.0 - 4.0.6 Spring for Apache Kafka 3.0.0 - 3.3.16 Spring for Apache Kafka 2.9.0 - 2.9.14 Spring for Apache Kafka 2.8.12 and earlier

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-59317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-27T20:17:57Z",
    "severity": "MODERATE"
  },
  "details": "DeadLetterPublishingRecovererFactory reads the retry_topic-original-timestamp header from an inbound ConsumerRecord and passes its raw bytes directly to new BigInteger(header.value()) with no length or format validation.\nSpring for Apache Kafka 4.1.0\nSpring for Apache Kafka 4.0.0 - 4.0.6\nSpring for Apache Kafka 3.0.0 - 3.3.16\nSpring for Apache Kafka 2.9.0 - 2.9.14\nSpring for Apache Kafka 2.8.12 and earlier",
  "id": "GHSA-v648-fvf7-jrg2",
  "modified": "2026-08-27T21:31:50Z",
  "published": "2026-08-27T21:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59317"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-59317"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V7CJ-VM62-R38R

Vulnerability from github – Published: 2022-12-13 18:30 – Updated: 2025-01-14 12:31
VLAI
Details

Affected devices do not check the TFTP blocksize correctly. This could allow an authenticated attacker to read from an uninitialized buffer that potentially contains previously allocated data.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-46143"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-13T16:15:00Z",
    "severity": "LOW"
  },
  "details": "Affected devices do not check the TFTP blocksize correctly. This could allow an authenticated attacker to read from an uninitialized buffer that potentially contains previously allocated data.",
  "id": "GHSA-v7cj-vm62-r38r",
  "modified": "2025-01-14T12:31:47Z",
  "published": "2022-12-13T18:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46143"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-180704.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-413565.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-180704.pdf"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-413565.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

No CAPEC attack patterns related to this CWE.