fast-xml-parser: Quadratic CPU consumption scanning unterminated stop-node tags
Published 10 Nov 2026 · Updated 10 Nov 2026
Is your project on an affected fast-xml-parser?
Affected package
- Affected
- <5.12.0
- Fixed in
- 5.12.0
npm install fast-xml-parser@5.12.0Details
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()callsreadStopNodeData()after a matching stop node opensOrderedObjParser.js:810— callsreadTagExp()for every non-special<OrderedObjParser.js:688-722—tagExpWithClosingIndex()scans to end-of-input and returnsundefinedwhen no>existsOrderedObjParser.js:812-818— on failure,iisn't advanced, so the next<repeats the same full scanOrderedObjParser.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).
Is GHSA-474x-hrwr-fgx4 in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected fast-xml-parser, and gives you the command that fixes it.
More advisories for fast-xml-parser
- HighCVE-2026-73569fast-xml-parser: Repeated DOCTYPE declarations reset entity expansion limits · 21 Jul 2026
- MediumCVE-2026-41650fast-xml-parser XMLBuilder: XML Comment and CDATA Injection via Unescaped Delimiters · 22 Apr 2026
- MediumCVE-2026-33349Entity Expansion Limits Bypassed When Set to Zero Due to JavaScript Falsy Evaluation in fast-xml-parser · 19 Mar 2026
- HighCVE-2026-33036fast-xml-parser affected by numeric entity expansion bypassing all entity expansion limits (incomplete fix for CVE-2026-26278) · 17 Mar 2026
- LowCVE-2026-27942fast-xml-parser has stack overflow in XMLBuilder with preserveOrder · 26 Feb 2026
- CriticalCVE-2026-25896fast-xml-parser has an entity encoding bypass via regex injection in DOCTYPE entity names · 20 Feb 2026
References
- Linkgithub.com/NaturalIntelligence/fast-xml-parser/security/advisories/GHSA-474x-hrwr-fgx4
- Linkgithub.com/NaturalIntelligence/fast-xml-parser/commit/0c3659348364959da62954b73728fb3bd05ebcb4
- Packagegithub.com/NaturalIntelligence/fast-xml-parser
- Linkgithub.com/NaturalIntelligence/fast-xml-parser/releases/tag/v5.12.0
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.