GHSA-X4FP-J954-R2F4
Vulnerability from github – Published: 2026-09-08 21:01 – Updated: 2026-09-08 21:01Summary
On the @xmldom/xmldom 0.8.x line, parsing an XML end tag whose name is followed by a long run
of whitespace and then a non-whitespace character triggers quadratic-time regular-expression
backtracking (ReDoS), so a single small crafted end tag stalls the Node.js event loop. It is reachable
from DOMParser.parseFromString under default options, unauthenticated, before any validity
check — an availability-only denial of service. The 0.9.x line is not affected.
Details
lib/sax.js (release-0.8.x, commit e5c1480) trims trailing whitespace from a captured end-tag name
with an unanchored global regex:
lib/sax.jsline 120: https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/sax.js#L120
/[ \t\n\r]+$/g
Applied to a string shaped whitespace-run + one non-whitespace char (e.g. the content of an end tag
</ … x>), the engine must, for every starting position, extend [ws]+ to the end and then fail
the $ anchor when the trailing non-whitespace char is present — classic O(n²) backtracking in the
length of the whitespace run. The trimmed substring is delimited only by indexOf('>'), so the
attacker controls its length directly.
Proof of Concept
const { DOMParser } = require('@xmldom/xmldom'); // 0.8.x
const n = 64 * 1024;
const payload = '<r></' + ' '.repeat(n) + 'x>';
console.time('parse');
new DOMParser().parseFromString(payload, 'text/xml');
console.timeEnd('parse');
Measured (Node 18) — time quadruples per doubling of the whitespace run (canonical O(n²)):
| Whitespace run | Isolated regex | End-to-end parseFromString (0.8.13) |
|---|---|---|
| 4 KB | 5.6 ms | 5.7 ms |
| 8 KB | 22.7 ms | 22.5 ms |
| 16 KB | 88.6 ms | 92 ms |
| 32 KB | 354 ms | 361 ms |
| 64 KB | 1434 ms | 1452 ms |
| 128 KB | 5761 ms | — |
Impact
Availability only: a single parse of a small crafted document blocks the Node.js event loop for the duration of the quadratic scan (≈1.4 s at 64 KB; multi-second with larger inputs). No memory blow-up, 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.
Affected Versions
Affected on the 0.7.x and 0.8.x lines (the trailing-whitespace trim was added in 0.7.0, present
through 0.8.14); the fix targets the 0.8.x LTS patch. The 0.9.x line rewrote end-tag parsing to
an anchored linear matcher and never had this regex, so it is not affected. No published unscoped
xmldom is affected — the vulnerable code exists only in a 0.7.0 git tag that was never released to
npm (npm view xmldom → latest = 0.6.0).
Fix Applied
Anchors the end-tag trailing-whitespace trim so it runs in linear time instead of backtracking quadratically on a long whitespace run. Byte-identical output. Non-breaking; 0.8.x-only.
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.
{
"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"
}
]
}
],
"aliases": [
"CVE-2026-83619"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T21:01:09Z",
"nvd_published_at": "2026-09-01T15:17:40Z",
"severity": "HIGH"
},
"details": "## Summary\n\nOn the `@xmldom/xmldom` **`0.8.x`** line, parsing an XML end tag whose name is followed by a long run\nof whitespace and then a non-whitespace character triggers quadratic-time regular-expression\nbacktracking (ReDoS), so a single small crafted end tag stalls the Node.js event loop. It is reachable\nfrom `DOMParser.parseFromString` under **default options**, unauthenticated, before any validity\ncheck \u2014 an availability-only denial of service. The `0.9.x` line is **not** affected.\n\n## Details\n\n`lib/sax.js` (release-0.8.x, commit `e5c1480`) trims trailing whitespace from a captured end-tag name\nwith an unanchored global regex:\n\n- `lib/sax.js` line 120: https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/sax.js#L120\n\n```js\n/[ \\t\\n\\r]+$/g\n```\n\nApplied to a string shaped `whitespace-run + one non-whitespace char` (e.g. the content of an end tag\n`\u003c/ \u2026 x\u003e`), the engine must, for every starting position, extend `[ws]+` to the end and then fail\nthe `$` anchor when the trailing non-whitespace char is present \u2014 classic O(n\u00b2) backtracking in the\nlength of the whitespace run. The trimmed substring is delimited only by `indexOf(\u0027\u003e\u0027)`, so the\nattacker controls its length directly.\n\n## Proof of Concept\n\n```js\nconst { DOMParser } = require(\u0027@xmldom/xmldom\u0027); // 0.8.x\nconst n = 64 * 1024;\nconst payload = \u0027\u003cr\u003e\u003c/\u0027 + \u0027 \u0027.repeat(n) + \u0027x\u003e\u0027;\nconsole.time(\u0027parse\u0027);\nnew DOMParser().parseFromString(payload, \u0027text/xml\u0027);\nconsole.timeEnd(\u0027parse\u0027);\n```\n\nMeasured (Node 18) \u2014 time quadruples per doubling of the whitespace run (canonical O(n\u00b2)):\n\n| Whitespace run | Isolated regex | End-to-end `parseFromString` (0.8.13) |\n|---|---|---|\n| 4 KB | 5.6 ms | 5.7 ms |\n| 8 KB | 22.7 ms | 22.5 ms |\n| 16 KB | 88.6 ms | 92 ms |\n| 32 KB | 354 ms | 361 ms |\n| 64 KB | 1434 ms | 1452 ms |\n| 128 KB | 5761 ms | \u2014 |\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 scan (\u22481.4 s at 64 KB; multi-second with larger inputs). No memory\nblow-up, no data exposure, no integrity impact. Because XML is routinely accepted from untrusted\nsources and parsed with default options, one request can stall a server.\n\n## Affected Versions\n\nAffected on the `0.7.x` and `0.8.x` lines (the trailing-whitespace trim was added in `0.7.0`, present\nthrough `0.8.14`); the fix targets the `0.8.x` LTS patch. The `0.9.x` line rewrote end-tag parsing to\nan anchored linear matcher and never had this regex, so it is **not** affected. No published unscoped\n`xmldom` is affected \u2014 the vulnerable code exists only in a `0.7.0` git tag that was never released to\nnpm (`npm view xmldom` \u2192 `latest` = 0.6.0).\n\n## Fix Applied\n\nAnchors the end-tag trailing-whitespace trim so it runs in linear time instead of\nbacktracking quadratically on a long whitespace run. Byte-identical output. Non-breaking; 0.8.x-only.\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.",
"id": "GHSA-x4fp-j954-r2f4",
"modified": "2026-09-08T21:01:09Z",
"published": "2026-09-08T21:01:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/security/advisories/GHSA-x4fp-j954-r2f4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-83619"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/pull/1072"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/commit/3abb0934f5a8a84d83a1f9cde0f2bd04c08b2a09"
},
{
"type": "PACKAGE",
"url": "https://github.com/xmldom/xmldom"
},
{
"type": "WEB",
"url": "https://github.com/xmldom/xmldom/releases/tag/0.8.15"
}
],
"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: End-tag Whitespace-Trim Regex ReDoS \u2014 quadratic backtracking in the 0.8.x end-tag parser"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.