Common Weakness Enumeration

CWE-835

Allowed

Loop with Unreachable Exit Condition ('Infinite Loop')

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.

1201 vulnerabilities reference this CWE, most recent first.

GHSA-RVQR-F374-3QQW

Vulnerability from github – Published: 2022-05-02 03:23 – Updated: 2022-05-02 03:23
VLAI
Details

libclamav/untar.c in ClamAV before 0.95 allows remote attackers to cause a denial of service (infinite loop) via a crafted TAR file that causes (1) clamd and (2) clamscan to hang.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2009-1270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-04-08T16:30:00Z",
    "severity": "HIGH"
  },
  "details": "libclamav/untar.c in ClamAV before 0.95 allows remote attackers to cause a denial of service (infinite loop) via a crafted TAR file that causes (1) clamd and (2) clamscan to hang.",
  "id": "GHSA-rvqr-f374-3qqw",
  "modified": "2022-05-02T03:23:15Z",
  "published": "2022-05-02T03:23:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1270"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/49846"
    },
    {
      "type": "WEB",
      "url": "https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1462"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2009/Sep/msg00004.html"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/53461"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/34716"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/36701"
    },
    {
      "type": "WEB",
      "url": "http://support.apple.com/kb/HT3865"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2009/dsa-1771"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2009:097"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2009/04/07/6"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/34357"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/usn-754-1"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2009/0934"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-RW4J-R22C-9GC3

Vulnerability from github – Published: 2026-09-17 14:53 – Updated: 2026-09-17 14:53
VLAI
Summary
AsyncSSH: asyncio event-loop freeze via SSH maximum packet size = 0 in SSH_MSG_CHANNEL_OPEN / OPEN_CONFIRMATION
Details

Summary

A malicious SSH server can wedge an AsyncSSH client, and an authenticated client can wedge an AsyncSSH server, by sending a channel maximum packet size of 0 in SSH_MSG_CHANNEL_OPEN_CONFIRMATION (server→client) or SSH_MSG_CHANNEL_OPEN (client→server). AsyncSSH stores the peer-supplied value verbatim with no lower-bound check; the first time channel data is written, SSHChannel._flush_send_buf enters a synchronous infinite loop that cannot be interrupted by asyncio.wait_for or any timeout. The loop body has no await, so it blocks the entire asyncio event loop — for a server, one malicious authenticated channel freezes all current and future connections.

RFC 4254 §5.1 leaves receiver behavior for a peer-reported "maximum packet size = 0" undefined, so the value must be rejected rather than stored.

Root cause

asyncssh/channel.py:

# process_open (server side)        -- line 465
self._send_pktsize = send_pktsize    # peer value, no >= 1 check

# process_open_confirmation (client) -- line 528
self._send_pktsize = send_pktsize    # peer value, no >= 1 check

# _flush_send_buf                    -- lines 305-320
while self._send_buf and self._send_window:
    pktsize = min(self._send_window, self._send_pktsize)  # 0 when peer sends 0
    buf, datatype = self._send_buf[0]
    if len(buf) > pktsize:          # True for any buffered data
        data = buf[:pktsize]        # empty (b'')
        del buf[:pktsize]           # no-op
    ...
    self._send_window -= len(data)  # -= 0, unchanged

With _send_pktsize == 0, pktsize is 0, so buf[:0] is empty, del buf[:0] is a no-op, and _send_window is never decremented — the while condition is permanently true, and with no await in the body the event loop is blocked.

Impact

  • Client vector (primary): a malicious SSH server replies to the client's channel open with maximum packet size = 0; the client wedges on its first channel write. The attacker is the server, so it needs no valid credentials.
  • Server vector: an authenticated client opens a channel with maximum packet size = 0; any server-side channel write wedges the AsyncSSH server's event loop, freezing every current and future connection. A single low-privilege account can take the whole server down.

Both vectors are a single SSH message, deterministic, and cause total availability loss for the affected process.

Affected versions

<= 2.23.1 (latest release, 2026-06-06); also present on master (channel.py:465/528 unguarded). Verified end-to-end on 2.23.1.

Verification

The maintainer's proposed fix (reject send_pktsize == 0 in connection.py _process_channel_open / _process_channel_open_confirmation) was applied to 2.23.1 and re-tested end-to-end over TCP:

  • Unpatched: malicious server (paramiko forcing max_packet_size=0 in OPEN_CONFIRMATION) + real asyncssh client → client event loop wedges.
  • Patched: the guard fires inside _process_channel_open_confirmation, the malicious value is rejected, the connection closes cleanly (ChannelOpenError: SSH connection closed), and the client does not wedge.

The maintainer (Ron Frederick) independently confirmed the freeze and noted that even shutting the server down does not break clients out of the loop.

Reproducers available: a focused harness driving the real SSHChannel._flush_send_buf with _send_pktsize=0, and an end-to-end malicious_server.py (paramiko) + client.py (real asyncssh) pair. The end-to-end client repro uses asyncio.new_event_loop() (not get_event_loop()) for Python 3.14 compatibility.

Suggested fix (maintainer's approach)

In connection.py, after each send_pktsize = packet.get_uint32() in _process_channel_open and _process_channel_open_confirmation:

if send_pktsize == 0:
    raise ProtocolError('Invalid maximum packet size')

CVSS

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (6.5 Medium). An earlier draft quoted 7.5 High ("100% CPU"); the synchronous loop burns ~100% of one core's worth of CPU but, being single-threaded, the OS scheduler spreads it across cores, so the real impact is event-loop / connection freeze, not machine-wide CPU exhaustion.

References

  • RFC 4254 §5.1 (channel "maximum packet size"; behavior for 0 is undefined).
  • The same maximum packet size = 0 send-loop wedge was confirmed in several other independent SSH implementations (different languages/runtimes) and reported to each maintainer separately.

Credits

Reported by zhangph (afldl), 2026-06-20. ```

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.23.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "asyncssh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-62949"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T14:53:01Z",
    "nvd_published_at": "2026-09-16T20:17:26Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA malicious SSH server can wedge an AsyncSSH **client**, and an authenticated\nclient can wedge an AsyncSSH **server**, by sending a channel `maximum packet\nsize` of `0` in `SSH_MSG_CHANNEL_OPEN_CONFIRMATION` (server\u2192client) or\n`SSH_MSG_CHANNEL_OPEN` (client\u2192server). AsyncSSH stores the peer-supplied value\nverbatim with no lower-bound check; the first time channel data is written,\n`SSHChannel._flush_send_buf` enters a **synchronous infinite loop** that cannot\nbe interrupted by `asyncio.wait_for` or any timeout. The loop body has no\n`await`, so it blocks the entire asyncio event loop \u2014 for a server, one\nmalicious authenticated channel freezes **all** current and future connections.\n\nRFC 4254 \u00a75.1 leaves receiver behavior for a peer-reported \"maximum packet\nsize = 0\" undefined, so the value must be rejected rather than stored.\n\n## Root cause\n\n`asyncssh/channel.py`:\n\n```python\n# process_open (server side)        -- line 465\nself._send_pktsize = send_pktsize    # peer value, no \u003e= 1 check\n\n# process_open_confirmation (client) -- line 528\nself._send_pktsize = send_pktsize    # peer value, no \u003e= 1 check\n\n# _flush_send_buf                    -- lines 305-320\nwhile self._send_buf and self._send_window:\n    pktsize = min(self._send_window, self._send_pktsize)  # 0 when peer sends 0\n    buf, datatype = self._send_buf[0]\n    if len(buf) \u003e pktsize:          # True for any buffered data\n        data = buf[:pktsize]        # empty (b\u0027\u0027)\n        del buf[:pktsize]           # no-op\n    ...\n    self._send_window -= len(data)  # -= 0, unchanged\n```\n\nWith `_send_pktsize == 0`, `pktsize` is `0`, so `buf[:0]` is empty,\n`del buf[:0]` is a no-op, and `_send_window` is never decremented \u2014 the\n`while` condition is permanently true, and with no `await` in the body the\nevent loop is blocked.\n\n## Impact\n\n- **Client vector (primary):** a malicious SSH server replies to the client\u0027s\n  channel open with `maximum packet size = 0`; the client wedges on its first\n  channel write. The attacker is the server, so it needs no valid credentials.\n- **Server vector:** an authenticated client opens a channel with\n  `maximum packet size = 0`; any server-side channel write wedges the AsyncSSH\n  server\u0027s event loop, freezing **every** current and future connection. A\n  single low-privilege account can take the whole server down.\n\nBoth vectors are a single SSH message, deterministic, and cause total\navailability loss for the affected process.\n\n## Affected versions\n\n\u003c= 2.23.1 (latest release, 2026-06-06); also present on `master`\n(channel.py:465/528 unguarded). Verified end-to-end on 2.23.1.\n\n## Verification\n\nThe maintainer\u0027s proposed fix (reject `send_pktsize == 0` in `connection.py`\n`_process_channel_open` / `_process_channel_open_confirmation`) was applied to\n2.23.1 and re-tested end-to-end over TCP:\n\n- **Unpatched:** malicious server (paramiko forcing `max_packet_size=0` in\n  OPEN_CONFIRMATION) + real asyncssh client \u2192 client event loop wedges.\n- **Patched:** the guard fires inside `_process_channel_open_confirmation`, the\n  malicious value is rejected, the connection closes cleanly\n  (`ChannelOpenError: SSH connection closed`), and the client does **not** wedge.\n\nThe maintainer (Ron Frederick) independently confirmed the freeze and noted that\n**even shutting the server down does not break clients out of the loop**.\n\nReproducers available: a focused harness driving the real\n`SSHChannel._flush_send_buf` with `_send_pktsize=0`, and an end-to-end\n`malicious_server.py` (paramiko) + `client.py` (real asyncssh) pair. The\nend-to-end client repro uses `asyncio.new_event_loop()` (not `get_event_loop()`)\nfor Python 3.14 compatibility.\n\n## Suggested fix (maintainer\u0027s approach)\n\nIn `connection.py`, after each `send_pktsize = packet.get_uint32()` in\n`_process_channel_open` and `_process_channel_open_confirmation`:\n\n```python\nif send_pktsize == 0:\n    raise ProtocolError(\u0027Invalid maximum packet size\u0027)\n```\n\n## CVSS\n\n`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H` (6.5 Medium). An earlier draft\nquoted 7.5 High (\"100% CPU\"); the synchronous loop burns ~100% of one core\u0027s\nworth of CPU but, being single-threaded, the OS scheduler spreads it across\ncores, so the real impact is event-loop / connection freeze, not machine-wide\nCPU exhaustion.\n\n## References\n\n- RFC 4254 \u00a75.1 (channel \"maximum packet size\"; behavior for 0 is undefined).\n- The same `maximum packet size = 0` send-loop wedge was confirmed in several\n  other independent SSH implementations (different languages/runtimes) and\n  reported to each maintainer separately.\n\n## Credits\n\nReported by zhangph (afldl), 2026-06-20.\n```",
  "id": "GHSA-rw4j-r22c-9gc3",
  "modified": "2026-09-17T14:53:01Z",
  "published": "2026-09-17T14:53:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ronf/asyncssh/security/advisories/GHSA-rw4j-r22c-9gc3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62949"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ronf/asyncssh/commit/756cbae5350789ce9735f15f704bae9b5a3608b8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ronf/asyncssh/commit/9c354270c009285525e126721e8ed5fbed1f8a67"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ronf/asyncssh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ronf/asyncssh/releases/tag/v2.24.0"
    }
  ],
  "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"
    }
  ],
  "summary": "AsyncSSH: asyncio event-loop freeze via SSH maximum packet size = 0 in SSH_MSG_CHANNEL_OPEN / OPEN_CONFIRMATION"
}

GHSA-V347-C52R-65XM

Vulnerability from github – Published: 2022-05-13 01:07 – Updated: 2025-04-20 03:34
VLAI
Details

The xhci_kick_epctx function in hw/usb/hcd-xhci.c in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (infinite loop and QEMU process crash) via vectors related to control transfer descriptor sequence.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-5973"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-27T15:59:00Z",
    "severity": "MODERATE"
  },
  "details": "The xhci_kick_epctx function in hw/usb/hcd-xhci.c in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (infinite loop and QEMU process crash) via vectors related to control transfer descriptor sequence.",
  "id": "GHSA-v347-c52r-65xm",
  "modified": "2025-04-20T03:34:50Z",
  "published": "2022-05-13T01:07:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5973"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:2392"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:2408"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1421626"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/09/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg01101.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201704-01"
    },
    {
      "type": "WEB",
      "url": "http://git.qemu-project.org/?p=qemu.git%3Ba=commit%3Bh=f89b60f6e5fee3923bedf80e82b4e5efc1bb156b"
    },
    {
      "type": "WEB",
      "url": "http://git.qemu-project.org/?p=qemu.git;a=commit;h=f89b60f6e5fee3923bedf80e82b4e5efc1bb156b"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2017/02/13/11"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/96220"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V3Q7-57MP-77XP

Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2022-05-24 17:22
VLAI
Details

In Wireshark 3.2.0 to 3.2.4, the GVCP dissector could go into an infinite loop. This was addressed in epan/dissectors/packet-gvcp.c by ensuring that an offset increases in all situations.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-15466"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-05T11:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Wireshark 3.2.0 to 3.2.4, the GVCP dissector could go into an infinite loop. This was addressed in epan/dissectors/packet-gvcp.c by ensuring that an offset increases in all situations.",
  "id": "GHSA-v3q7-57mp-77xp",
  "modified": "2022-05-24T17:22:23Z",
  "published": "2022-05-24T17:22:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15466"
    },
    {
      "type": "WEB",
      "url": "https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16029"
    },
    {
      "type": "WEB",
      "url": "https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=11f40896b696e4e8c7f8b2ad96028404a83a51a4"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/02/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202007-13"
    },
    {
      "type": "WEB",
      "url": "https://www.wireshark.org/security/wnpa-sec-2020-09.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-08/msg00026.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-08/msg00038.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-V456-CHPW-6MMW

Vulnerability from github – Published: 2022-08-10 00:00 – Updated: 2022-08-18 19:15
VLAI
Summary
Apache Avro Rust SDK vulnerable to reader looping in cycle endlessly, consuming CPU
Details

It is possible to provide data to be read that leads the reader to loop in cycles endlessly, consuming CPU. This issue affects Rust applications using Apache Avro Rust SDK prior to 0.14.0 (previously known as avro-rs). Users should update to apache-avro version 0.14.0 which addresses this issue.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "apache-avro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-35724"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-08-18T19:15:54Z",
    "nvd_published_at": "2022-08-09T07:15:00Z",
    "severity": "HIGH"
  },
  "details": "It is possible to provide data to be read that leads the reader to loop in cycles endlessly, consuming CPU. This issue affects Rust applications using Apache Avro Rust SDK prior to 0.14.0 (previously known as avro-rs). Users should update to apache-avro version 0.14.0 which addresses this issue.",
  "id": "GHSA-v456-chpw-6mmw",
  "modified": "2022-08-18T19:15:54Z",
  "published": "2022-08-10T00:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35724"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/a0x8o/avro"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/771z1nwrpkn1ovmyfb2fm65mchdxgy7p"
    }
  ],
  "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"
    }
  ],
  "summary": "Apache Avro Rust SDK vulnerable to reader looping in cycle endlessly, consuming CPU"
}

GHSA-V4XF-P7R4-PFPQ

Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2022-05-13 01:53
VLAI
Details

In FreeBSD before 11.1-STABLE, 11.1-RELEASE-p9, 10.4-STABLE, 10.4-RELEASE-p8 and 10.3-RELEASE-p28, the length field of the ipsec option header does not count the size of the option header itself, causing an infinite loop when the length is zero. This issue can allow a remote attacker who is able to send an arbitrary packet to cause the machine to crash.

Severity
7.5 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-6918"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-04-04T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "In FreeBSD before 11.1-STABLE, 11.1-RELEASE-p9, 10.4-STABLE, 10.4-RELEASE-p8 and 10.3-RELEASE-p28, the length field of the ipsec option header does not count the size of the option header itself, causing an infinite loop when the length is zero. This issue can allow a remote attacker who is able to send an arbitrary packet to cause the machine to crash.",
  "id": "GHSA-v4xf-p7r4-pfpq",
  "modified": "2022-05-13T01:53:13Z",
  "published": "2022-05-13T01:53:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-6918"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2019/May/77"
    },
    {
      "type": "WEB",
      "url": "https://security.FreeBSD.org/advisories/FreeBSD-SA-18:05.ipsec.asc"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT210090"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT210091"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2019/Jun/6"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/103666"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1040628"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/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.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
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
Show details on source website
To clipboard 

{
  "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-V594-44HM-2J7P

Vulnerability from github – Published: 2025-07-28 21:31 – Updated: 2025-11-05 00:31
VLAI
Details

There is a defect in the CPython “tarfile” module affecting the “TarFile” extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives.

This vulnerability can be mitigated by including the following patch after importing the “tarfile” module:

import tarfile

def _block_patched(self, count):     if count < 0: # pragma: no cover         raise tarfile.InvalidHeaderError("invalid offset")     return _block_patched._orig_block(self, count)

_block_patched._orig_block = tarfile.TarInfo._block tarfile.TarInfo._block = _block_patched

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-8194"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-28T19:15:43Z",
    "severity": "HIGH"
  },
  "details": "There is a defect in the CPython \u201ctarfile\u201d module affecting the \u201cTarFile\u201d extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives. \n\nThis vulnerability can be mitigated by including the following patch after importing the \u201ctarfile\u201d module:\n\n\n\nimport tarfile\n\ndef _block_patched(self, count):\n\u00a0 \u00a0 if count \u003c 0:  # pragma: no cover\n\u00a0 \u00a0 \u00a0 \u00a0 raise tarfile.InvalidHeaderError(\"invalid offset\")\n\u00a0 \u00a0 return _block_patched._orig_block(self, count)\n\n_block_patched._orig_block = tarfile.TarInfo._block\ntarfile.TarInfo._block = _block_patched",
  "id": "GHSA-v594-44hm-2j7p",
  "modified": "2025-11-05T00:31:23Z",
  "published": "2025-07-28T21:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8194"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/issues/130577"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/pull/137027"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/57f5981d6260ed21266e0c26951b8564cc252bc2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/7040aa54f14676938970e10c5f74ea93cd56aa38"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/73f03e4808206f71eb6b92c579505a220942ef19"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/b4ec17488eedec36d3c05fec127df71c0071f6cb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/c9d9f78feb1467e73fd29356c040bde1c104f29f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/cdae923ffe187d6ef916c0f665a31249619193fe"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/fbc2a0ca9ac8aff6887f8ddf79b87b4510277227"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/sethmlarson/1716ac5b82b73dbcbf23ad2eff8b33e1"
    },
    {
      "type": "WEB",
      "url": "https://mail.python.org/archives/list/security-announce@python.org/thread/ZULLF3IZ726XP5EY7XJ7YIN3K5MDYR2D"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/07/28/1"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/07/28/2"
    }
  ],
  "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-V5GM-HMRC-RGFQ

Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44
VLAI
Details

An issue was discovered in QPDF before 7.0.0. There is an infinite loop due to looping xref tables in QPDF.cc.

Severity
5.5 (Medium)
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-18186"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-02-13T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in QPDF before 7.0.0. There is an infinite loop due to looping xref tables in QPDF.cc.",
  "id": "GHSA-v5gm-hmrc-rgfq",
  "modified": "2022-05-13T01:44:36Z",
  "published": "2022-05-13T01:44:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18186"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qpdf/qpdf/issues/149"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qpdf/qpdf/commit/85f05cc57ffa0a863d9d9b23e73acea9410b2937"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3638-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V6C2-XWV6-8XF7

Vulnerability from github – Published: 2026-03-17 20:04 – Updated: 2026-03-19 21:00
VLAI
Summary
music-metadata has an infinite loop vulnerability in ASF parser
Details

Summary

music-metadata's ASF parser (parseExtensionObject() in lib/asf/AsfParser.ts:112-158) enters an infinite loop when a sub-object inside the ASF Header Extension Object has objectSize = 0.

Root Cause

When objectSize is 0: 1. remaining = 0 - 24 = -24 2. tokenizer.ignore(-24) moves the read position backward by 24 bytes 3. extensionSize -= 0 (loop counter never decreases) 4. while (extensionSize > 0) never exits 5. The same 24-byte header is re-read infinitely

This is the same pattern as CVE-2026-31808 (GHSA-5v7r-6r5c-r473) in file-type — strtok3's AbstractTokenizer.ignore() accepts negative values without validation.

Affected Methods

  • parseFile() — HANGS (FileTokenizer inherits vulnerable ignore())
  • parseBuffer() — HANGS (BufferTokenizer inherits vulnerable ignore())
  • parseStream() — NOT affected (ReadStreamTokenizer has own ignore() that throws RangeError)

Impact

A 100-byte crafted .asf file permanently hangs any application using parseFile() or parseBuffer(). music-metadata has 2.2M weekly npm downloads.

Suggested Fix

Validate objectSize >= minimumHeaderSize before calculating the payload. Or fix strtok3's AbstractTokenizer.ignore() to reject negative values.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 11.12.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "music-metadata"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.12.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32256"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-17T20:04:48Z",
    "nvd_published_at": "2026-03-18T04:17:25Z",
    "severity": "HIGH"
  },
  "details": "# Summary\n\nmusic-metadata\u0027s ASF parser (`parseExtensionObject()` in `lib/asf/AsfParser.ts:112-158`) enters an infinite loop when a sub-object inside the ASF Header Extension Object has `objectSize = 0`.\n\n## Root Cause\n\nWhen objectSize is 0:\n1. `remaining = 0 - 24 = -24`\n2. `tokenizer.ignore(-24)` moves the read position backward by 24 bytes\n3. `extensionSize -= 0` (loop counter never decreases)\n4. `while (extensionSize \u003e 0)` never exits\n5. The same 24-byte header is re-read infinitely\n\nThis is the same pattern as CVE-2026-31808 (GHSA-5v7r-6r5c-r473) in file-type \u2014 strtok3\u0027s `AbstractTokenizer.ignore()` accepts negative values without validation.\n\n## Affected Methods\n- `parseFile()` \u2014 HANGS (FileTokenizer inherits vulnerable ignore())\n- `parseBuffer()` \u2014 HANGS (BufferTokenizer inherits vulnerable ignore())\n- `parseStream()` \u2014 NOT affected (ReadStreamTokenizer has own ignore() that throws RangeError)\n\n## Impact\nA 100-byte crafted .asf file permanently hangs any application using parseFile() or parseBuffer(). music-metadata has 2.2M weekly npm downloads.\n\n## Suggested Fix\nValidate `objectSize \u003e= minimumHeaderSize` before calculating the payload. Or fix strtok3\u0027s `AbstractTokenizer.ignore()` to reject negative values.",
  "id": "GHSA-v6c2-xwv6-8xf7",
  "modified": "2026-03-19T21:00:51Z",
  "published": "2026-03-17T20:04:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/security/advisories/GHSA-v6c2-xwv6-8xf7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32256"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Borewit/music-metadata"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Borewit/music-metadata/releases/tag/v11.12.3"
    }
  ],
  "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"
    }
  ],
  "summary": "music-metadata has an infinite loop vulnerability in ASF parser"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list