LowGHSA-474x-hrwr-fgx4CVE-2026-126066

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?

Private repo? Upload its lockfile instead, or connect GitHub to check every repo.

Affected package

Affected
<5.12.0
Fixed in
5.12.0
Update to the fixed version for your release line, for example:npm install fast-xml-parser@5.12.0

Details

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).

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
All 13 advisories for fast-xml-parser

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.