CVE-2026-126066: fast-xml-parser · Quadratic CPU consumption scanning unterminated stop-node tags
Affects fast-xml-parserSource GCVE Database
Not known to be exploited · CVSS 3.7 Low : upgrade to 5.12.0 when convenient.
Data as of 10 Nov 2026, 22:34 UTC
Thin evidence
One scorer or none| CNA (GitHub_M) | CVSS 3.1 | 3.7 |
|---|
- Patch
- Available – fixed in 5.12.0
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:LExploitation evidence
Disclosed: evidence found.
CVE published 10 Nov 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 10 Nov 2026.
What to do
Upgrade fast-xml-parser to 5.12.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| npmfast-xml-parser | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
### Summary With the non-default stopNodes option, a stop node's body with many "<a " fragments and no closing ">" anywhere after makes readStopNodeData() rescan the entire remaining input from every "<". The failed lookahead is neither cached nor bounded, so n fragments cost O(n²) before the parser throws. Availability-only (CPU exhaustion), needs the non-default stopNodes option — not benchmarked yet, see Proof of Concept. ### Details **CWE-407** — Inefficient Algorithmic Complexity **Code** - `OrderedObjParser.js:520` — `parseXml()` calls `readStopNodeData()` after a matching stop node opens - `OrderedObjParser.js:810` — calls `readTagExp()` for every non-special `<` - `OrderedObjParser.js:688-722` — `tagExpWithClosingIndex()` scans to end-of-input and returns `undefined` when no `>` exists - `OrderedObjParser.js:812-818` — on failure, `i` isn't advanced, so the next `<` repeats the same full scan - `OrderedObjParser.js:423` — the main parse loop throws immediately on the same failure; only the stop-node path retries **Root cause:** a failed closing-`>` lookahead is neither cached nor bounded — `n` copies of `<a ` with no later `>` means `n` scans over the remaining input, O(n²) work, before it finally throws. **Fix** 1. Throw immediately in `readStopNodeData()` when `readTagExp()` returns `undefined` 2. Or break the loop on the first failed scan 3. Or find the next `>` once and reuse/bound that result 4. Add a test asserting near-linear scaling when payload size doubles ### Proof of concept Not benchmarked — static-analysis finding, confidence 0.5. To confirm: configure `stopNodes` matching a root element. Build input as `'<stop>' + '<a '.repeat(n)`. Time `parse()` until it throws `Unexpected end of <tag>`. Start around n=10,000 and double it — quadratic should show ~4x time per doubling, linear ~2x. Control: same input with a `>` present, or `stopNodes` unset. ### Impact CPU-exhaustion DoS in Node.js services parsing untrusted XML with `stopNodes` enabled. A ~100KB payload is estimated at ~10⁹ character operations (roughly a second or more of blocked event loop) — analytical estimate, not a benchmark. No confidentiality/integrity impact. CVSS 3.1: `AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L` (3.7, Low).
References
- github.com/NaturalIntelligence/fast-xml-parser/security/advisories/GHSA-474x-hrwr-fgx4 (opens in a new tab)
- github.com/NaturalIntelligence/fast-xml-parser/commit/0c3659348364959da62954b73728fb3bd05ebcb4 (opens in a new tab)
- github.com/NaturalIntelligence/fast-xml-parser (opens in a new tab)
- github.com/NaturalIntelligence/fast-xml-parser/releases/tag/v5.12.0 (opens in a new tab)