Vulnerability-Lookup

GHSA-8RR7-CVQ3-GMFH

Vulnerability from github – Published: 2026-09-01 20:28 – Updated: 2026-09-01 20:28

Summary

league/commonmark: Denial of service via distinctly-named attributes in the Attributes extension

Details

Impact

AttributesExtension ships with the library but must be explicitly registered on the Environment; it is not included in CommonMarkConverter, GithubFlavoredMarkdownConverter, or GithubFlavoredMarkdownExtension. Applications that do not register AttributesExtension are not affected by this advisory.

Two paths in the extension re-process every attribute a node has already collected each time another attribute is applied to it. When the attributes carry distinct names, the collected set grows by one on every step and is walked again in full, so a run of n attributes costs O(n²).

1. Attribute nodes resolving to a common target (affected from 1.5.0).

AttributesListener::processDocument() merges each attribute node into the set accumulated for its target, then filters the result. Both operations traverse that entire set: AttributesHelper::mergeAttributes() rebuilds it with array_merge(), and AttributesHelper::filterAttributes() matches a regular expression against every name in it. A run of attribute nodes sharing one target therefore re-walks a set that grows by a key per node.

Two input shapes reach this path: adjacent inline attributes at the start of a block ({a0="v"}{a1="v"}…, where quoting the values is what keeps them separate — an unquoted value swallows the }{ that follows it), and a chain of attribute blocks held at their default target by reference definitions ({a0=v} / [a]: u / {a1=v} / [a]: u / …).

256 KB of adjacent inline attributes takes 20.0 seconds to convert, against 0.09 seconds once patched.

2. Consecutive attribute-block lines (affected from 2.0.0).

AttributesBlockContinueParser::tryContinue() merges each continuation line into the block's accumulated attributes, again rebuilding the whole set on every line. One distinct attribute per line ({a0=v} / {a1=v} / …) grows it by a key each time.

256 KB of such lines takes 1.9 seconds to convert while producing zero bytes of output, against 0.08 seconds once patched.

Relationship to GHSA-jjv6-8j6v-6j52. The fix released in 2.9.1 for that advisory made the class attribute cheap to accumulate, but left every other attribute name on the original path. Applications that upgraded to 2.9.1 or 2.9.2 remain exposed to this variant.

Overall impact. An unauthenticated attacker who can submit Markdown to an affected application can consume disproportionate CPU time with a comparatively small request, occupying PHP workers and preventing legitimate requests from completing. The impact is limited to availability: no data is disclosed, rendered output is unchanged, and no rendering restriction is bypassed.

Patches

The issue is patched in 2.10.0. Both paths now fold each node — or each line — into the accumulated attributes at a cost proportional to that node or line alone, rather than re-merging and re-filtering everything gathered so far. Rendered output is unchanged, down to the order in which attributes appear.

The listener path affects 1.5.0 through 2.9.2. The continuation-line path affects 2.0.0 through 2.9.2. The 1.x release line is no longer supported, so its users must upgrade to 2.10.0 or later.

Workarounds

If you cannot upgrade immediately:

Do not register AttributesExtension when converting untrusted Markdown. This fully removes both paths.
If the extension is required, impose a strict maximum input length before conversion. Because the cost is quadratic, the cap must be small to meaningfully bound worst-case CPU time.

The attributes/allow allow-list added in 2.7.0 is not a mitigation. A non-empty allow-list happens to bound the first path, because unlisted names are discarded before they accumulate, but it does nothing for the second: continuation lines are merged while parsing, before any filtering takes place.

Restricting conversion to trusted users, applying strict execution-time limits, and rate-limiting requests reduce exposure but are not substitutes for upgrading.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "league/commonmark"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "2.10.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1050",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-01T20:28:40Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\n`AttributesExtension` ships with the library but must be explicitly registered on the `Environment`; it is not included in `CommonMarkConverter`, `GithubFlavoredMarkdownConverter`, or `GithubFlavoredMarkdownExtension`. **Applications that do not register `AttributesExtension` are not affected by this advisory.**\n\nTwo paths in the extension re-process every attribute a node has already collected each time another attribute is applied to it. When the attributes carry distinct names, the collected set grows by one on every step and is walked again in full, so a run of *n* attributes costs O(n\u00b2).\n\n**1. Attribute nodes resolving to a common target (affected from 1.5.0).**\n\n`AttributesListener::processDocument()` merges each attribute node into the set accumulated for its target, then filters the result. Both operations traverse that entire set: `AttributesHelper::mergeAttributes()` rebuilds it with `array_merge()`, and `AttributesHelper::filterAttributes()` matches a regular expression against every name in it. A run of attribute nodes sharing one target therefore re-walks a set that grows by a key per node.\n\nTwo input shapes reach this path: adjacent inline attributes at the start of a block (`{a0=\"v\"}{a1=\"v\"}\u2026`, where quoting the values is what keeps them separate \u2014 an unquoted value swallows the `}{` that follows it), and a chain of attribute blocks held at their default target by reference definitions (`{a0=v}` / `[a]: u` / `{a1=v}` / `[a]: u` / \u2026).\n\n256 KB of adjacent inline attributes takes 20.0 seconds to convert, against 0.09 seconds once patched.\n\n**2. Consecutive attribute-block lines (affected from 2.0.0).**\n\n`AttributesBlockContinueParser::tryContinue()` merges each continuation line into the block\u0027s accumulated attributes, again rebuilding the whole set on every line. One distinct attribute per line (`{a0=v}` / `{a1=v}` / \u2026) grows it by a key each time.\n\n256 KB of such lines takes 1.9 seconds to convert while producing **zero bytes of output**, against 0.08 seconds once patched.\n\n**Relationship to GHSA-jjv6-8j6v-6j52.** The fix released in 2.9.1 for that advisory made the `class` attribute cheap to accumulate, but left every other attribute name on the original path. **Applications that upgraded to 2.9.1 or 2.9.2 remain exposed to this variant.**\n\n**Overall impact.** An unauthenticated attacker who can submit Markdown to an affected application can consume disproportionate CPU time with a comparatively small request, occupying PHP workers and preventing legitimate requests from completing. The impact is limited to availability: no data is disclosed, rendered output is unchanged, and no rendering restriction is bypassed.\n\n### Patches\n\nThe issue is patched in `2.10.0`. Both paths now fold each node \u2014 or each line \u2014 into the accumulated attributes at a cost proportional to that node or line alone, rather than re-merging and re-filtering everything gathered so far. Rendered output is unchanged, down to the order in which attributes appear.\n\nThe listener path affects `1.5.0` through `2.9.2`. The continuation-line path affects `2.0.0` through `2.9.2`. The 1.x release line is no longer supported, so its users must upgrade to `2.10.0` or later.\n\n### Workarounds\n\nIf you cannot upgrade immediately:\n\n- **Do not register `AttributesExtension`** when converting untrusted Markdown. This fully removes both paths.\n- If the extension is required, **impose a strict maximum input length before conversion**. Because the cost is quadratic, the cap must be small to meaningfully bound worst-case CPU time.\n\nThe `attributes/allow` allow-list added in 2.7.0 is **not** a mitigation. A non-empty allow-list happens to bound the first path, because unlisted names are discarded before they accumulate, but it does nothing for the second: continuation lines are merged while parsing, before any filtering takes place.\n\nRestricting conversion to trusted users, applying strict execution-time limits, and rate-limiting requests reduce exposure but are not substitutes for upgrading.",
  "id": "GHSA-8rr7-cvq3-gmfh",
  "modified": "2026-09-01T20:28:40Z",
  "published": "2026-09-01T20:28:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/security/advisories/GHSA-8rr7-cvq3-gmfh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/commit/f27eb720972490b5af4dbb635ad8634529faf9f2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thephpleague/commonmark"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/releases/tag/2.10.0"
    }
  ],
  "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": "league/commonmark: Denial of service via distinctly-named attributes in the Attributes extension"
}

GHSA-8X48-8G7J-RQXP

Vulnerability from github – Published: 2026-08-27 18:32 – Updated: 2026-09-02 14:36

Withdrawn 2026-09-02

Summary

Duplicate Advisory: Quadratic-time DoS in PorterStemmer via long runs of 'y'

Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-ww6m-cw3f-q94g. This link is maintained to preserve external references.

Original Description

nltk PorterStemmer in versions <= 3.10.2 (fixed in 3.10.3) contains an inefficient-algorithmic-complexity denial of service in PorterStemmer.stem(). The _is_consonant() helper walks backward over the entire run of trailing 'y' characters on every call, and _measure() invokes it for each stem position, causing O(n^2) behavior. A single ~20-50 KB untrusted token consisting of a long run of the letter 'y' followed by a matching suffix (e.g., 'ness') can pin a CPU core for seconds to minutes, causing availability impact.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "nltk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.10.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-02T14:36:04Z",
    "nvd_published_at": "2026-08-27T17:21:02Z",
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-ww6m-cw3f-q94g. This link is maintained to preserve external references.\n\n## Original Description\nnltk PorterStemmer in versions \u003c= 3.10.2 (fixed in 3.10.3) contains an inefficient-algorithmic-complexity denial of service in PorterStemmer.stem(). The _is_consonant() helper walks backward over the entire run of trailing \u0027y\u0027 characters on every call, and _measure() invokes it for each stem position, causing O(n^2) behavior. A single ~20-50 KB untrusted token consisting of a long run of the letter \u0027y\u0027 followed by a matching suffix (e.g., \u0027ness\u0027) can pin a CPU core for seconds to minutes, causing availability impact.",
  "id": "GHSA-8x48-8g7j-rqxp",
  "modified": "2026-09-02T14:36:04Z",
  "published": "2026-08-27T18:32:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/security/advisories/GHSA-ww6m-cw3f-q94g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81722"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/nltk-porterstemmer-before-3.10.3-quadratic-time-dos"
    }
  ],
  "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/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"
    }
  ],
  "summary": "Duplicate Advisory: Quadratic-time DoS in PorterStemmer via long runs of \u0027y\u0027",
  "withdrawn": "2026-09-02T14:36:04Z"
}

GHSA-93Q9-CRCW-VWGQ

Vulnerability from github – Published: 2025-11-28 09:30 – Updated: 2026-06-02 15:31

Details

In libexpat through 2.7.3, a crafted file with an approximate size of 2 MiB can lead to dozens of seconds of processing time.

Severity

2.9 (Low)


                  
                    CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-66382"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-28T07:15:57Z",
    "severity": "LOW"
  },
  "details": "In libexpat through 2.7.3, a crafted file with an approximate size of 2 MiB can lead to dozens of seconds of processing time.",
  "id": "GHSA-93q9-crcw-vwgq",
  "modified": "2026-06-02T15:31:50Z",
  "published": "2025-11-28T09:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66382"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libexpat/libexpat/issues/1076"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-253495.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/12/02/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-93R5-FHX6-VMG9

Vulnerability from github – Published: 2026-09-08 21:00 – Updated: 2026-09-08 21:00

Summary

xmldom: Quadratic-time parsing via the malformed-input recovery path — `parseElementStartPart` re-scan and `normalize()` adjacent-text merge

Details

Summary

xmldom's malformed-input error-recovery path has two quadratic-time (O(n²)) behaviors that a single crafted input triggers together, so a tiny, highly compressible document (tens of KB) stalls the Node.js event loop for multiple seconds. It is reachable from DOMParser.parseFromString under default options — i.e. from unauthenticated, network-delivered XML — making this an unauthenticated denial of service. One of the two behaviors, the normalize() adjacent-text merge, is additionally reachable programmatically — via a plain normalize() call on a DOM built with adjacent text nodes, independent of the parser — so its fix must live in normalize(), not only in a parser bound.

Details

Finding A — `parseElementStartPart` quadratic re-scan

A < character is not a delimiter in any tag-parsing state, so parseElementStartPart scans forward character-by-character over any embedded < until it reaches the next > (or end of input), then validates the accumulated slice as a tag name and throws invalid tagName: on failure. The main loop catches this, reports an error, sets end = -1, and recovers by advancing a single character (appendText(Math.max(tagStart, start) + 1)). With a long run of < and a distant >, each of the O(n) recovery retries performs an O(n) scan plus an O(n) anchored regex validation over the growing candidate ⇒ O(n²).

Code (0.9.x, bb7a085dc5ba1eea3212388509b97bb4b4af32b9):

parseElementStartPart character scan — https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/sax.js#L263-L461
tag-name validation (setTagName → throws invalid tagName) — https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/sax.js#L886-L891
main-loop catch → error + end = -1 — https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/sax.js#L234-L242
single-character recovery fallback — https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/sax.js#L247

Code (0.8.x, e5c14802592685bb872c042c54c3f73758875c85):

parseElementStartPart — https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/sax.js#L227
catch → error + end = -1 — https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/sax.js#L202-L208
recovery fallback — https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/sax.js#L213
setTagName validation — https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/sax.js#L616-L621

Finding B — `normalize()` adjacent-text O(K²) merge

endDocument() calls document.normalize(). For a parent with K adjacent text nodes (produced by the one-character recovery of Finding A), normalize() performs K−1 merges. Each merge does a removeChild — which re-indexes all child nodes of the parent (O(K)) — and an appendData — which rebuilds the accumulator string this.data + text (O(K)). Total: O(K²).

Well-formed XML cannot produce adjacent text-node siblings through the parser (each text run is one node; comments, CDATA, PIs, and elements sit between runs), so the parse-path trigger for Finding B is the malformed-input recovery that emits single-character text nodes. The same O(K²) merge is, however, independently reachable via the public normalize() API on a programmatically built tree (see "Finding B is additionally reachable programmatically" below).

Code (0.9.x, bb7a085dc5ba1eea3212388509b97bb4b4af32b9):

endDocument → normalize() — https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/dom-parser.js#L418-L420
normalize() adjacent-text merge — https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/dom.js#L1336-L1356
removeChild re-index-all branch — https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/dom.js#L1788-L1798
appendData string rebuild — https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/dom.js#L2786-L2790

Code (0.8.x, e5c14802592685bb872c042c54c3f73758875c85):

endDocument → normalize() — https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/dom-parser.js#L213-L214
normalize() merge — https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/dom.js#L529-L549
removeChild re-index-all branch — https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/dom.js#L756-L773
appendData string rebuild — https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/dom.js#L1533

Finding B is additionally reachable programmatically (no parser involved)

Node.prototype.normalize() is public API on every Document/Element. A tree built entirely through the ordinary DOM API — new DOMImplementation().createDocument(...), then K× createTextNode + appendChild on one parent — reaches the same O(K²) merge when the application calls normalize(), with no parsing and no error-recovery. The parser is only one of the two callers of the vulnerable merge:

the parser's automatic endDocument() → document.normalize() (the parse-path trigger above), and
any explicit application call to the public normalize() on a tree with adjacent text nodes.

XMLSerializer does not call normalize(), so serializing an un-merged tree is O(total text), not O(K²); the O(K²) surface is exactly those two normalize() callers. Consequently a parser-side bound alone cannot remediate Finding B — the fix must live in normalize().

Affected Versions

Both findings are present across the full published @xmldom/xmldom history — both currently-maintained versions (0.8.x and 0.9.x) are affected — and across the retired unscoped xmldom line. Finding B's normalize() merge is additionally reachable programmatically: a direct normalize() call on a DOM built with adjacent text nodes hits the same O(K²) merge, independent of the parser — so, unlike Finding A, it does not require the malformed-input recovery path.

Proof of Concept

Default DOMParser, no options. The input is trivially compressible (a< / a<> repeated) and never throws — it is parsed via the recovery path.

const { DOMParser } = require('@xmldom/xmldom');

// Silence the expected `error`-level recovery reports (default handler logs
// them to console.error without throwing; only fatalError throws).
console.error = function () {};

function timeParse(label, xml, mime) {
  const t0 = process.hrtime.bigint();
  new DOMParser().parseFromString(xml, mime); // completes; no exception
  const ms = Number(process.hrtime.bigint() - t0) / 1e6;
  console.log(label + '  bytes=' + Buffer.byteLength(xml) + '  time=' + ms.toFixed(1) + ' ms');
}

for (const N of [4000, 8000, 16000, 32000]) {
  // Finding A: long re-scans, O(n^2) during parse.
  timeParse('A N=' + N, '<r>' + 'a<'.repeat(N) + '</r>', 'text/xml');
  // Finding B: short re-scans (cheap parse) but K adjacent text nodes -> O(K^2) in normalize().
  timeParse('B N=' + N, '<r>' + 'a<>'.repeat(N) + '</r>', 'text/html');
  // Combined: ONE input hits both A and B under the default parser.
  timeParse('C N=' + N, '<r>' + 'a<'.repeat(N) + '</r>', 'text/xml');
}

Measured on Node v18.20.8 (absolute ms vary by host; the load-bearing fact is that doubling the input ~quadruples the time — canonical O(n²)):

Finding A, isolated ("<r>" + "a<"×N + "</r>", normalize disabled to isolate the re-scan):

N	input bytes	`@xmldom/xmldom` 0.9.10	0.8.13
2000	4007	43 ms	37 ms
4000	8007	129 ms	106 ms
8000	16007	434 ms	424 ms
16000	32007	1629 ms	1611 ms

Finding B, isolated ("<r>" + "a<>"×N + "</r>", time attributable to normalize()):

K (N)	input bytes	0.9.10	0.8.13
4000	12007	120 ms	165 ms
8000	24007	589 ms	771 ms
16000	48007	3142 ms	4448 ms
32000	96007	12127 ms	12951 ms

Combined (default parser, both findings; "<r>" + "a<"×N + "</r>"):

N	input bytes	0.9.10	0.8.13
4000	8007	341 ms	397 ms
8000	16007	1894 ms	1641 ms
16000	32007	4398 ms	7661 ms

~32 KB of input → several seconds of single-threaded event-loop stall.

Finding B via the public `normalize()` API (no parser)

const { DOMImplementation } = require('@xmldom/xmldom');

function timeNormalize(K) {
  const doc = new DOMImplementation().createDocument(null, 'r', null);
  const el = doc.documentElement;
  for (let i = 0; i < K; i++) el.appendChild(doc.createTextNode('x')); // K adjacent text nodes
  const t0 = process.hrtime.bigint();
  doc.normalize();                                    // O(K^2) merge — no parsing involved
  const ms = Number(process.hrtime.bigint() - t0) / 1e6;
  console.log('K=' + K + '  time=' + ms.toFixed(1) + ' ms');
}
for (const K of [2000, 4000, 8000, 16000, 32000]) timeNormalize(K);

Measured on Node v18.20.8 (doubling K ~quadruples the time — O(K²)):

K	0.9.10	0.8.13
2000	5.7 ms	5.6 ms
32000	1263 ms	1704 ms

This path is reachable by any application that builds a DOM from attacker-influenced data and calls normalize(), entirely independent of DOMParser.

Impact

Availability only: a single parse of a small crafted document blocks the Node.js event loop for the duration of the quadratic work (multiple seconds at tens of KB; larger inputs scale as O(n²)). No memory blow-up beyond transient strings, no data exposure, no integrity impact. Because XML is routinely accepted from untrusted sources and parsed with default options, one request can stall a server. The payloads are highly compressible, so any endpoint accepting compressed XML faces additional amplification. Finding B is additionally reachable via an explicit normalize() call on a programmatically built DOM (see Proof of Concept), so applications that construct a document from attacker-influenced data and normalize it are exposed even without parsing.

Severity note

The complexity is quadratic, not exponential, so a multi-second stall requires tens-to-hundreds of KB of input. VA:H reflects that xmldom applies no input-size limit and the path runs on default-options parsing, so a single unbounded parse can fully stall the event loop.

Fix Applied

Two independent, non-breaking fixes shipped together — each alone leaves the other's quadratic cost dominating the default parse. Finding A — terminate the malformed tag-name scan at an embedded <, so error recovery is linear instead of O(n²). DOM output is unchanged; only the reported error-message text differs (error strings are not a semver contract). Finding B — merge adjacent text nodes in normalize() in O(K) instead of O(K²), which also closes the same slowdown reachable programmatically through a direct normalize() call. Both ship on both maintained versions.

Severity

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

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.14"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@xmldom/xmldom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.7.0"
            },
            {
              "fixed": "0.8.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.11"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@xmldom/xmldom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0"
            },
            {
              "fixed": "0.9.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "xmldom"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.0"
            },
            {
              "last_affected": "0.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-83614"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-08T21:00:41Z",
    "nvd_published_at": "2026-09-01T15:17:39Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`xmldom`\u0027s malformed-input **error-recovery path** has two quadratic-time (O(n\u00b2)) behaviors that a\nsingle crafted input triggers together, so a tiny, highly compressible document (tens of KB) stalls\nthe Node.js event loop for multiple seconds. It is reachable from `DOMParser.parseFromString` under\n**default options** \u2014 i.e. from unauthenticated, network-delivered XML \u2014 making this an unauthenticated\ndenial of service. One of the two behaviors, the `normalize()` adjacent-text merge, is **additionally\nreachable programmatically** \u2014 via a plain `normalize()` call on a DOM built with adjacent text nodes,\nindependent of the parser \u2014 so its fix must live in `normalize()`, not only in a parser bound.\n\n## Details\n\n### Finding A \u2014 `parseElementStartPart` quadratic re-scan\n\nA `\u003c` character is not a delimiter in any tag-parsing state, so `parseElementStartPart` scans\nforward character-by-character over any embedded `\u003c` until it reaches the next `\u003e` (or end of\ninput), then validates the accumulated slice as a tag name and throws `invalid tagName:` on failure.\nThe main loop catches this, reports an `error`, sets `end = -1`, and recovers by advancing a single\ncharacter (`appendText(Math.max(tagStart, start) + 1)`). With a long run of `\u003c` and a distant `\u003e`,\neach of the O(n) recovery retries performs an O(n) scan plus an O(n) anchored regex validation over\nthe growing candidate \u21d2 **O(n\u00b2)**.\n\nCode (0.9.x, `bb7a085dc5ba1eea3212388509b97bb4b4af32b9`):\n\n- `parseElementStartPart` character scan \u2014 https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/sax.js#L263-L461\n- tag-name validation (`setTagName` \u2192 throws `invalid tagName`) \u2014 https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/sax.js#L886-L891\n- main-loop `catch` \u2192 `error` + `end = -1` \u2014 https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/sax.js#L234-L242\n- single-character recovery fallback \u2014 https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/sax.js#L247\n\nCode (0.8.x, `e5c14802592685bb872c042c54c3f73758875c85`):\n\n- `parseElementStartPart` \u2014 https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/sax.js#L227\n- `catch` \u2192 `error` + `end = -1` \u2014 https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/sax.js#L202-L208\n- recovery fallback \u2014 https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/sax.js#L213\n- `setTagName` validation \u2014 https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/sax.js#L616-L621\n\n### Finding B \u2014 `normalize()` adjacent-text O(K\u00b2) merge\n\n`endDocument()` calls `document.normalize()`. For a parent with K adjacent text nodes (produced by\nthe one-character recovery of Finding A), `normalize()` performs K\u22121 merges. Each merge does a\n`removeChild` \u2014 which re-indexes **all** child nodes of the parent (O(K)) \u2014 and an `appendData` \u2014\nwhich rebuilds the accumulator string `this.data + text` (O(K)). Total: **O(K\u00b2)**.\n\nWell-formed XML cannot produce adjacent text-node siblings *through the parser* (each text run is one\nnode; comments, CDATA, PIs, and elements sit between runs), so the **parse-path** trigger for Finding B\nis the malformed-input recovery that emits single-character text nodes. The same O(K\u00b2) merge is,\nhowever, independently reachable via the public `normalize()` API on a programmatically built tree\n(see \"Finding B is additionally reachable programmatically\" below).\n\nCode (0.9.x, `bb7a085dc5ba1eea3212388509b97bb4b4af32b9`):\n\n- `endDocument` \u2192 `normalize()` \u2014 https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/dom-parser.js#L418-L420\n- `normalize()` adjacent-text merge \u2014 https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/dom.js#L1336-L1356\n- `removeChild` re-index-all branch \u2014 https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/dom.js#L1788-L1798\n- `appendData` string rebuild \u2014 https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/dom.js#L2786-L2790\n\nCode (0.8.x, `e5c14802592685bb872c042c54c3f73758875c85`):\n\n- `endDocument` \u2192 `normalize()` \u2014 https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/dom-parser.js#L213-L214\n- `normalize()` merge \u2014 https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/dom.js#L529-L549\n- `removeChild` re-index-all branch \u2014 https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/dom.js#L756-L773\n- `appendData` string rebuild \u2014 https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/dom.js#L1533\n\n### Finding B is additionally reachable programmatically (no parser involved)\n\n`Node.prototype.normalize()` is public API on every `Document`/`Element`. A tree built entirely through\nthe ordinary DOM API \u2014 `new DOMImplementation().createDocument(...)`, then K\u00d7 `createTextNode` +\n`appendChild` on one parent \u2014 reaches the **same** O(K\u00b2) merge when the application calls `normalize()`,\nwith **no** parsing and **no** error-recovery. The parser is only *one* of the two callers of the\nvulnerable merge:\n\n- the parser\u0027s automatic `endDocument()` \u2192 `document.normalize()` (the parse-path trigger above), and\n- any explicit application call to the public `normalize()` on a tree with adjacent text nodes.\n\n`XMLSerializer` does **not** call `normalize()`, so serializing an un-merged tree is O(total text), not\nO(K\u00b2); the O(K\u00b2) surface is exactly those two `normalize()` callers. Consequently a parser-side bound\nalone cannot remediate Finding B \u2014 the fix must live in `normalize()`.\n\n## Affected Versions\n\nBoth findings are present across the full published `@xmldom/xmldom` history \u2014 both\ncurrently-maintained versions (`0.8.x` and `0.9.x`) are affected \u2014 and across the retired unscoped\n`xmldom` line. Finding B\u0027s `normalize()` merge is additionally reachable **programmatically**: a\ndirect `normalize()` call on a DOM built with adjacent text nodes hits the same O(K\u00b2) merge,\nindependent of the parser \u2014 so, unlike Finding A, it does not require the malformed-input recovery\npath.\n\n## Proof of Concept\n\nDefault `DOMParser`, no options. The input is trivially compressible (`a\u003c` / `a\u003c\u003e` repeated) and\nnever throws \u2014 it is parsed via the recovery path.\n\n```js\nconst { DOMParser } = require(\u0027@xmldom/xmldom\u0027);\n\n// Silence the expected `error`-level recovery reports (default handler logs\n// them to console.error without throwing; only fatalError throws).\nconsole.error = function () {};\n\nfunction timeParse(label, xml, mime) {\n  const t0 = process.hrtime.bigint();\n  new DOMParser().parseFromString(xml, mime); // completes; no exception\n  const ms = Number(process.hrtime.bigint() - t0) / 1e6;\n  console.log(label + \u0027  bytes=\u0027 + Buffer.byteLength(xml) + \u0027  time=\u0027 + ms.toFixed(1) + \u0027 ms\u0027);\n}\n\nfor (const N of [4000, 8000, 16000, 32000]) {\n  // Finding A: long re-scans, O(n^2) during parse.\n  timeParse(\u0027A N=\u0027 + N, \u0027\u003cr\u003e\u0027 + \u0027a\u003c\u0027.repeat(N) + \u0027\u003c/r\u003e\u0027, \u0027text/xml\u0027);\n  // Finding B: short re-scans (cheap parse) but K adjacent text nodes -\u003e O(K^2) in normalize().\n  timeParse(\u0027B N=\u0027 + N, \u0027\u003cr\u003e\u0027 + \u0027a\u003c\u003e\u0027.repeat(N) + \u0027\u003c/r\u003e\u0027, \u0027text/html\u0027);\n  // Combined: ONE input hits both A and B under the default parser.\n  timeParse(\u0027C N=\u0027 + N, \u0027\u003cr\u003e\u0027 + \u0027a\u003c\u0027.repeat(N) + \u0027\u003c/r\u003e\u0027, \u0027text/xml\u0027);\n}\n```\n\nMeasured on Node v18.20.8 (absolute ms vary by host; the load-bearing fact is that doubling the\ninput ~quadruples the time \u2014 canonical O(n\u00b2)):\n\nFinding A, isolated (`\"\u003cr\u003e\" + \"a\u003c\"\u00d7N + \"\u003c/r\u003e\"`, normalize disabled to isolate the re-scan):\n\n| N | input bytes | `@xmldom/xmldom` 0.9.10 | 0.8.13 |\n|--:|--:|--:|--:|\n| 2000 | 4007 | 43 ms | 37 ms |\n| 4000 | 8007 | 129 ms | 106 ms |\n| 8000 | 16007 | 434 ms | 424 ms |\n| 16000 | 32007 | 1629 ms | 1611 ms |\n\nFinding B, isolated (`\"\u003cr\u003e\" + \"a\u003c\u003e\"\u00d7N + \"\u003c/r\u003e\"`, time attributable to `normalize()`):\n\n| K (N) | input bytes | 0.9.10 | 0.8.13 |\n|--:|--:|--:|--:|\n| 4000 | 12007 | 120 ms | 165 ms |\n| 8000 | 24007 | 589 ms | 771 ms |\n| 16000 | 48007 | 3142 ms | 4448 ms |\n| 32000 | 96007 | 12127 ms | 12951 ms |\n\nCombined (default parser, both findings; `\"\u003cr\u003e\" + \"a\u003c\"\u00d7N + \"\u003c/r\u003e\"`):\n\n| N | input bytes | 0.9.10 | 0.8.13 |\n|--:|--:|--:|--:|\n| 4000 | 8007 | 341 ms | 397 ms |\n| 8000 | 16007 | 1894 ms | 1641 ms |\n| 16000 | 32007 | 4398 ms | 7661 ms |\n\n~32 KB of input \u2192 several seconds of single-threaded event-loop stall.\n\n### Finding B via the public `normalize()` API (no parser)\n\n```js\nconst { DOMImplementation } = require(\u0027@xmldom/xmldom\u0027);\n\nfunction timeNormalize(K) {\n  const doc = new DOMImplementation().createDocument(null, \u0027r\u0027, null);\n  const el = doc.documentElement;\n  for (let i = 0; i \u003c K; i++) el.appendChild(doc.createTextNode(\u0027x\u0027)); // K adjacent text nodes\n  const t0 = process.hrtime.bigint();\n  doc.normalize();                                    // O(K^2) merge \u2014 no parsing involved\n  const ms = Number(process.hrtime.bigint() - t0) / 1e6;\n  console.log(\u0027K=\u0027 + K + \u0027  time=\u0027 + ms.toFixed(1) + \u0027 ms\u0027);\n}\nfor (const K of [2000, 4000, 8000, 16000, 32000]) timeNormalize(K);\n```\n\nMeasured on Node v18.20.8 (doubling K ~quadruples the time \u2014 O(K\u00b2)):\n\n| K | 0.9.10 | 0.8.13 |\n|--:|--:|--:|\n| 2000 | 5.7 ms | 5.6 ms |\n| 32000 | 1263 ms | 1704 ms |\n\nThis path is reachable by any application that builds a DOM from attacker-influenced data and calls\n`normalize()`, entirely independent of `DOMParser`.\n\n## Impact\n\nAvailability only: a single parse of a small crafted document blocks the Node.js event loop for the\nduration of the quadratic work (multiple seconds at tens of KB; larger inputs scale as O(n\u00b2)). No\nmemory blow-up beyond transient strings, no data exposure, no integrity impact. Because XML is\nroutinely accepted from untrusted sources and parsed with default options, one request can stall a\nserver. The payloads are highly compressible, so any endpoint accepting compressed XML faces\nadditional amplification. Finding B is additionally reachable via an explicit `normalize()` call on a\nprogrammatically built DOM (see Proof of Concept), so applications that construct a document from attacker-influenced\ndata and normalize it are exposed even without parsing.\n\n## Severity note\n\nThe complexity is **quadratic**, not exponential, so a multi-second stall requires\ntens-to-hundreds of KB of input. `VA:H` reflects that xmldom applies **no** input-size limit and the\npath runs on default-options parsing, so a single unbounded parse can fully stall the event loop.\n\n## Fix Applied\n\nTwo independent, non-breaking fixes shipped together \u2014 each alone leaves the other\u0027s quadratic cost dominating the default parse.\nFinding A \u2014 terminate the malformed tag-name scan at an embedded `\u003c`, so error recovery is linear instead of O(n\u00b2). DOM output is unchanged; only the reported error-message text differs (error strings are not a semver contract).\nFinding B \u2014 merge adjacent text nodes in `normalize()` in O(K) instead of O(K\u00b2), which also closes the same slowdown reachable programmatically through a direct `normalize()` call. Both ship on both maintained versions.",
  "id": "GHSA-93r5-fhx6-vmg9",
  "modified": "2026-09-08T21:00:41Z",
  "published": "2026-09-08T21:00:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/security/advisories/GHSA-93r5-fhx6-vmg9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-83614"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/pull/1071"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/pull/1072"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/commit/0748720b620555f8c222782dcab575cf0cf403b4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/commit/f40ccb861eee0acbf5ee4feb9a34932e87b329c9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xmldom/xmldom"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/releases/tag/0.8.15"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xmldom/xmldom/releases/tag/0.9.12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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": "xmldom: Quadratic-time parsing via the malformed-input recovery path \u2014 `parseElementStartPart` re-scan and `normalize()` adjacent-text merge"
}

GHSA-94XW-8RG2-4FMC

Vulnerability from github – Published: 2024-11-26 21:32 – Updated: 2024-11-26 21:32

Details

An issue was discovered in GitLab CE/EE affecting all versions starting from 15.6 prior to 17.4.5, starting from 17.5 prior to 17.5.3, starting from 17.6 prior to 17.6.1 which could cause Denial of Service via integrating a malicious harbor registry.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-8177"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-26T19:15:31Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in GitLab CE/EE affecting all versions starting from 15.6 prior to 17.4.5, starting from 17.5 prior to 17.5.3, starting from 17.6 prior to 17.6.1 which could cause Denial of Service via integrating a malicious harbor registry.",
  "id": "GHSA-94xw-8rg2-4fmc",
  "modified": "2024-11-26T21:32:24Z",
  "published": "2024-11-26T21:32:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8177"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2637996"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/480706"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9643-4QGH-G8MX

Vulnerability from github – Published: 2026-09-23 21:54 – Updated: 2026-09-23 21:54

Summary

elysia has Inefficient Algorithmic Complexity and Interpretation Conflict

Details

Elysia v1.4.28 is vulnerable to denial-of-service attacks due to CPU exhaustion in the form data normalization code.

Elysia uses getAll to retrieve value from FormData. It is called directly relative to the total number of key-value pairs in the form data. The total amount of work the for loop has to do grows quadratically, so doubling the number of unique key-value pairs quadruples the amount of work. In the above PoC, each .getAll call scans through all of the n key-value pairs in the form data. Because there are n unique keys in the form data, there are .getAll calls, so in total the form data normalizer has to scan n x n key-value pairs.

Impact

Endpoints using multipart/form-data

Patches

1.4.29

Workarounds

no 100% confirm workaround beside updating the patch

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "elysia"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56669"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-23T21:54:50Z",
    "nvd_published_at": "2026-07-08T21:16:50Z",
    "severity": "HIGH"
  },
  "details": "Elysia v1.4.28 is vulnerable to denial-of-service attacks due to CPU exhaustion in the form data normalization code.\n\nElysia uses `getAll` to retrieve value from FormData. It is called directly relative to the total number of key-value pairs in the form data. The total amount of work the for loop has to do grows quadratically, so doubling the number of unique key-value pairs quadruples the amount of work. In the above PoC, each .getAll call scans through all of the `n` key-value pairs in the form data. Because there are `n` unique keys in the form data, there are .getAll calls, so in total the form data normalizer has to scan `n` x `n` key-value pairs.\n\n### Impact\nEndpoints using `multipart/form-data`\n\n### Patches\n1.4.29\n\n### Workarounds\nno 100% confirm workaround beside updating the patch",
  "id": "GHSA-9643-4qgh-g8mx",
  "modified": "2026-09-23T21:54:50Z",
  "published": "2026-09-23T21:54:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/elysiajs/elysia/security/advisories/GHSA-9643-4qgh-g8mx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56669"
    },
    {
      "type": "WEB",
      "url": "https://github.com/elysiajs/elysia/commit/8358ff9efbcedf9534995f5977f26b9ceab59329"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/jviide/ea040eabe7bac058326174e2cd42dfd9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/elysiajs/elysia"
    },
    {
      "type": "WEB",
      "url": "https://github.com/elysiajs/elysia/releases/tag/1.4.29"
    }
  ],
  "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": "elysia has Inefficient Algorithmic Complexity and Interpretation Conflict"
}

GHSA-9F57-9RHG-4HVM

Vulnerability from github – Published: 2025-02-20 03:32 – Updated: 2025-02-20 20:18

Summary

Kwik hash collision vulnerability

Details

An issue was discovered in Kwik before 0.10.1. A hash collision vulnerability (in the hash table used to manage connections) allows remote attackers to cause a considerable CPU load on the server (a Hash DoS attack) by initiating connections with colliding Source Connection IDs (SCIDs).

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "tech.kwik:kwik"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-23020"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-20T20:18:50Z",
    "nvd_published_at": "2025-02-20T03:15:12Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Kwik before 0.10.1. A hash collision vulnerability (in the hash table used to manage connections) allows remote attackers to cause a considerable CPU load on the server (a Hash DoS attack) by initiating connections with colliding Source Connection IDs (SCIDs).",
  "id": "GHSA-9f57-9rhg-4hvm",
  "modified": "2025-02-20T20:18:50Z",
  "published": "2025-02-20T03:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23020"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ptrd/kwik/commit/b0733d72bad76bc5d8df2f4a7792ebb2539ebdc8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ncc-pbottine/QUIC-Hash-Dos-Advisory"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ptrd/kwik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ptrd/kwik/releases/tag/v0.10.1"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Kwik hash collision vulnerability"
}

GHSA-9F7V-8M4P-PV76

Vulnerability from github – Published: 2022-05-24 17:03 – Updated: 2024-04-26 09:30

Details

knot-resolver before version 4.3.0 is vulnerable to denial of service through high CPU utilization. DNS replies with very many resource records might be processed very inefficiently, in extreme cases taking even several CPU seconds for each such uncached message. For example, a few thousand A records can be squashed into one DNS message (limit is 64kB).

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2019-19331"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-404",
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-12-16T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "knot-resolver before version 4.3.0 is vulnerable to denial of service through high CPU utilization. DNS replies with very many resource records might be processed very inefficiently, in extreme cases taking even several CPU seconds for each such uncached message. For example, a few thousand A records can be squashed into one DNS message (limit is 64kB).",
  "id": "GHSA-9f7v-8m4p-pv76",
  "modified": "2024-04-26T09:30:33Z",
  "published": "2022-05-24T17:03:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19331"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-19331"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://www.knot-resolver.cz/2019-12-04-knot-resolver-4.3.0.html"
    }
  ],
  "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-9M86-7PMV-2852

Vulnerability from github – Published: 2026-03-02 22:03 – Updated: 2026-03-06 21:56

Summary

pypdf vulnerable to inefficient decoding of ASCIIHexDecode streams

Details

Impact

An attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing a stream which uses the /ASCIIHexDecode filter.

Patches

This has been fixed in pypdf==6.7.5.

Workarounds

If you cannot upgrade yet, consider applying the changes from PR #3666.

Severity

6.9 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pypdf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.7.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28804"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-02T22:03:45Z",
    "nvd_published_at": "2026-03-06T07:16:01Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nAn attacker who uses this vulnerability can craft a PDF which leads to long runtimes. This requires accessing a stream which uses the `/ASCIIHexDecode` filter.\n\n### Patches\nThis has been fixed in [pypdf==6.7.5](https://github.com/py-pdf/pypdf/releases/tag/6.7.5).\n\n### Workarounds\nIf you cannot upgrade yet, consider applying the changes from PR [#3666](https://github.com/py-pdf/pypdf/pull/3666).",
  "id": "GHSA-9m86-7pmv-2852",
  "modified": "2026-03-06T21:56:41Z",
  "published": "2026-03-02T22:03:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/security/advisories/GHSA-9m86-7pmv-2852"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28804"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/pull/3666"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/commit/648c627d2657447dfb1773412af05a0a5103b98f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/py-pdf/pypdf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/releases/tag/6.7.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "pypdf vulnerable to inefficient decoding of ASCIIHexDecode streams"
}

GHSA-9M98-W4QJ-8F6Q

Vulnerability from github – Published: 2026-08-25 21:31 – Updated: 2026-08-25 21:31

Details

An algorithmic complexity flaw exists in libsoup's HTTP Range header processing that persists after the CVE-2025-32907 fix.

CVE-2025-32907 addressed memory amplification when a client repeated the same range many times in a single Range header. Commit 9bb92f7a corrected merge correctness in soup_message_headers_get_ranges_internal() in libsoup/soup-message-headers.c, but the coalescing loop still removes merged ranges using g_array_remove_index() for each coalesced element. Because GArray is contiguous, each mid-array removal performs an O(N) memmove. When many identical satisfiable ranges are supplied (for example bytes=0-0 repeated thousands of times), the loop performs O(N²) work coalescing them into a single range.

The vulnerable path is reachable server-side from handle_partial_get() in libsoup/server/http1/soup-server-message-io-http1.c when a SoupServer handler returns HTTP 200 with a non-empty body. No authentication is required. The number of ranges is bounded only by the maximum request header size (~100 KiB), allowing roughly 25,000 ranges per request. Reporter measurements on libsoup HEAD containing the CVE-2025-32907 fix show ~90 ms single-core CPU per such request at the wire maximum, blocking the server's event loop for that duration.

This is a CPU exhaustion / availability issue only. No memory corruption or information disclosure occurs.

Affected: libsoup versions containing the CVE-2025-32907 fix but not merge request !550. Fixed upstream: MR !550 merged 2026-08-20, replacing per-element removal with O(N) in-place compaction and rejecting Range headers requesting more than 200 ranges. Upstream report: https://gitlab.gnome.org/GNOME/libsoup/-/issues/538 Related: CVE-2025-32907

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-77680"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-25T21:17:46Z",
    "severity": "MODERATE"
  },
  "details": "An algorithmic complexity flaw exists in libsoup\u0027s HTTP Range header processing that persists after the CVE-2025-32907 fix.\n\nCVE-2025-32907 addressed memory amplification when a client repeated the same range many times in a single Range header. Commit 9bb92f7a corrected merge correctness in soup_message_headers_get_ranges_internal() in libsoup/soup-message-headers.c, but the coalescing loop still removes merged ranges using g_array_remove_index() for each coalesced element. Because GArray is contiguous, each mid-array removal performs an O(N) memmove. When many identical satisfiable ranges are supplied (for example bytes=0-0 repeated thousands of times), the loop performs O(N\u00b2) work coalescing them into a single range.\n\nThe vulnerable path is reachable server-side from handle_partial_get() in libsoup/server/http1/soup-server-message-io-http1.c when a SoupServer handler returns HTTP 200 with a non-empty body. No authentication is required. The number of ranges is bounded only by the maximum request header size (~100 KiB), allowing roughly 25,000 ranges per request. Reporter measurements on libsoup HEAD containing the CVE-2025-32907 fix show ~90 ms single-core CPU per such request at the wire maximum, blocking the server\u0027s event loop for that duration.\n\nThis is a CPU exhaustion / availability issue only. No memory corruption or information disclosure occurs.\n\nAffected: libsoup versions containing the CVE-2025-32907 fix but not merge request !550.\nFixed upstream: MR !550 merged 2026-08-20, replacing per-element removal with O(N) in-place compaction and rejecting Range headers requesting more than 200 ranges.\nUpstream report: https://gitlab.gnome.org/GNOME/libsoup/-/issues/538\nRelated: CVE-2025-32907",
  "id": "GHSA-9m98-w4qj-8f6q",
  "modified": "2026-08-25T21:31:32Z",
  "published": "2026-08-25T21:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77680"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-32907"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-77680"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2520892"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.gnome.org/GNOME/libsoup/-/issues/538"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/550"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

CWE-407

Inefficient Algorithmic Complexity

Impact

Patches

Workarounds

Duplicate Advisory

Original Description

Summary

Details

Finding A — parseElementStartPart quadratic re-scan

Finding B — normalize() adjacent-text O(K²) merge

Finding B is additionally reachable programmatically (no parser involved)

Affected Versions

Proof of Concept

Finding B via the public normalize() API (no parser)

Impact

Severity note

Fix Applied

Impact

Patches

Workarounds

Impact

Patches

Workarounds

Finding A — `parseElementStartPart` quadratic re-scan

Finding B — `normalize()` adjacent-text O(K²) merge

Finding B via the public `normalize()` API (no parser)