https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 13 Nov 2026 11:52:04 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-126066 <p>fast-xml-parser allows users to process XML from JS object without C/C++ based libraries or callbacks. Prior to 5.12.0, when the non-default stopNodes option is enabled, readStopNodeData() in OrderedObjParser.js calls readTagExp() for each less-than character in an unterminated stop-node body and repeatedly rescans the remaining input while looking for a closing greater-than character. An attacker who supplies XML containing many tag fragments without a later closing character can cause quadratic rescanning before parsing fails, blocking a Node.js event loop and causing CPU-exhaustion denial of service. This issue is fixed in version 5.12.0.</p> <p>fast-xml-parser allows users to process XML from JS object without C/C++ based libraries or callbacks. Prior to 5.12.0, when the non-default stopNodes option is enabled, readStopNodeData() in OrderedObjParser.js calls readTagExp() for each less-than character in an unterminated stop-node body and repeatedly rescans the remaining input while looking for a closing greater-than character. An attacker who supplies XML containing many tag fragments without a later closing character can cause quadratic rescanning before parsing fails, blocking a Node.js event loop and causing CPU-exhaustion denial of service. This issue is fixed in version 5.12.0.</p> https://db.gcve.eu/vuln/fkie_cve-2026-126066 https://db.gcve.eu/vuln/ghsa-474x-hrwr-fgx4 <p><strong>Affected:</strong> npm: fast-xml-parser</p> <p>### Summary</p> <p>With the non-default stopNodes option, a stop node&#39;s body with many &#34;&lt;a &#34; fragments and no closing &#34;&gt;&#34; anywhere after makes readStopNodeData() rescan the entire remaining input from every &#34;&lt;&#34;. 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.</p> <p>### Details</p> <p>**CWE-407** — Inefficient Algorithmic Complexity</p> <p>**Code** - `OrderedObjParser.js:520` — `parseXml()` calls `readStopNodeData()` after a matching stop node opens - `OrderedObjParser.js:810` — calls `readTagExp()` for every non-special `&lt;` - `OrderedObjParser.js:688-722` — `tagExpWithClosingIndex()` scans to end-of-input and returns `undefined` when no `&gt;` exists - `OrderedObjParser.js:812-818` — on failure, `i` isn&#39;t advanced, so the next `&lt;` repeats the same full scan - `OrderedObjParser.js:423` — the main parse loop throws immediately on the same failure; only the stop-node path retries</p> <p>**Root cause:** a failed closing-`&gt;` lookahead is neither cached nor bounded — `n` copies of `&lt;a ` with no later `&gt;` means `n` scans over the remaining input, O(n²) work, before it finally throws.</p> <p>**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 `&gt;` once and reuse/bound that result 4. Add a test asserting near-linear scaling when payload size do…</p> <p><strong>Affected:</strong> npm: fast-xml-parser</p> <p>### Summary</p> <p>With the non-default stopNodes option, a stop node&#39;s body with many &#34;&lt;a &#34; fragments and no closing &#34;&gt;&#34; anywhere after makes readStopNodeData() rescan the entire remaining input from every &#34;&lt;&#34;. 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.</p> <p>### Details</p> <p>**CWE-407** — Inefficient Algorithmic Complexity</p> <p>**Code** - `OrderedObjParser.js:520` — `parseXml()` calls `readStopNodeData()` after a matching stop node opens - `OrderedObjParser.js:810` — calls `readTagExp()` for every non-special `&lt;` - `OrderedObjParser.js:688-722` — `tagExpWithClosingIndex()` scans to end-of-input and returns `undefined` when no `&gt;` exists - `OrderedObjParser.js:812-818` — on failure, `i` isn&#39;t advanced, so the next `&lt;` repeats the same full scan - `OrderedObjParser.js:423` — the main parse loop throws immediately on the same failure; only the stop-node path retries</p> <p>**Root cause:** a failed closing-`&gt;` lookahead is neither cached nor bounded — `n` copies of `&lt;a ` with no later `&gt;` means `n` scans over the remaining input, O(n²) work, before it finally throws.</p> <p>**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 `&gt;` once and reuse/bound that result 4. Add a test asserting near-linear scaling when payload size do…</p> https://db.gcve.eu/vuln/ghsa-474x-hrwr-fgx4