https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 07 Oct 2026 05:40:18 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-380898 EUVD-2026-380898 https://cve.radiocsirt.org/vuln/euvd-2026-380898 https://cve.radiocsirt.org/vuln/fkie_cve-2026-104182 <p>stream-json is a micro-library of stream components for processing JSON and JSONC with a minimal memory footprint. Prior to 3.6.0, the JSONC parser at stream-json/jsonc/parser.js and verifier at stream-json/jsonc/verifier.js restart comment-terminator scanning from the opening slash whenever a block or line comment spans an input chunk, while retaining the accumulated comment buffer. Delivering a large valid comment across many small chunks therefore causes quadratic CPU work and can stall the Node.js event loop. The maintainer characterizes the attack vector as local because the documented JSONC input is locally owned or user-controlled configuration, rather than input intended for the open internet. This JSONC-only scope does not include the plain JSON parser, which advances through and discards consumed string and number data. This issue is fixed in version 3.6.0.</p> <p>stream-json is a micro-library of stream components for processing JSON and JSONC with a minimal memory footprint. Prior to 3.6.0, the JSONC parser at stream-json/jsonc/parser.js and verifier at stream-json/jsonc/verifier.js restart comment-terminator scanning from the opening slash whenever a block or line comment spans an input chunk, while retaining the accumulated comment buffer. Delivering a large valid comment across many small chunks therefore causes quadratic CPU work and can stall the Node.js event loop. The maintainer characterizes the attack vector as local because the documented JSONC input is locally owned or user-controlled configuration, rather than input intended for the open internet. This JSONC-only scope does not include the plain JSON parser, which advances through and discards consumed string and number data. This issue is fixed in version 3.6.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-104182 https://cve.radiocsirt.org/vuln/ghsa-hqr4-qq8f-hg3x <p><strong>Affected:</strong> npm: stream-json</p> <p>## Summary</p> <p>The JSONC parser (`stream-json/jsonc/parser.js`) and verifier (`stream-json/jsonc/verifier.js`) scan a comment for its terminator starting from the comment&#39;s opening `/` on every input chunk. When a comment doesn&#39;t finish inside the current buffer, the scanner returns the comment&#39;s start offset and the buffer keeps the whole comment, so the next chunk re-scans everything seen so far. A single comment of length n delivered across many chunks costs O(n²) CPU.</p> <p>This is the same class as GHSA-528h-pc64-c93x (path filters, medium, CWE-407): an algorithmic-complexity re-scan in a streaming feature. It&#39;s a different code path though — the comment scanner in `handleComment`, which the 3.5.0 depth cap doesn&#39;t touch — so upgrading past that advisory doesn&#39;t help here. The plain JSON parser is fine: its strings and numbers advance and drop consumed bytes, and only comments retain and re-scan.</p> <p>## Proof of concept</p> <p>``` npm i stream-json@3.5.0 ```</p> <p>```js import Parser from &#39;stream-json/jsonc/parser.js&#39;;</p> <p>function feed(N) { return new Promise(resolve =&gt; { const stream = Parser.asStream(); // default options stream.on(&#39;data&#39;, () =&gt; {}); stream.on(&#39;error&#39;, () =&gt; {}); stream.on(&#39;end&#39;, resolve); const doc = &#39;/*&#39; + &#39;a&#39;.repeat(N) + &#39;*/1&#39;; // one valid, closed comment for (let i = 0; i &lt; doc.length; i += 16384) // 16 KB pieces, as a socket delivers a body stream.write(doc.slice(i, i + 16384)); stream.end(); }); } ```</p> <p>Timing the…</p> <p><strong>Affected:</strong> npm: stream-json</p> <p>## Summary</p> <p>The JSONC parser (`stream-json/jsonc/parser.js`) and verifier (`stream-json/jsonc/verifier.js`) scan a comment for its terminator starting from the comment&#39;s opening `/` on every input chunk. When a comment doesn&#39;t finish inside the current buffer, the scanner returns the comment&#39;s start offset and the buffer keeps the whole comment, so the next chunk re-scans everything seen so far. A single comment of length n delivered across many chunks costs O(n²) CPU.</p> <p>This is the same class as GHSA-528h-pc64-c93x (path filters, medium, CWE-407): an algorithmic-complexity re-scan in a streaming feature. It&#39;s a different code path though — the comment scanner in `handleComment`, which the 3.5.0 depth cap doesn&#39;t touch — so upgrading past that advisory doesn&#39;t help here. The plain JSON parser is fine: its strings and numbers advance and drop consumed bytes, and only comments retain and re-scan.</p> <p>## Proof of concept</p> <p>``` npm i stream-json@3.5.0 ```</p> <p>```js import Parser from &#39;stream-json/jsonc/parser.js&#39;;</p> <p>function feed(N) { return new Promise(resolve =&gt; { const stream = Parser.asStream(); // default options stream.on(&#39;data&#39;, () =&gt; {}); stream.on(&#39;error&#39;, () =&gt; {}); stream.on(&#39;end&#39;, resolve); const doc = &#39;/*&#39; + &#39;a&#39;.repeat(N) + &#39;*/1&#39;; // one valid, closed comment for (let i = 0; i &lt; doc.length; i += 16384) // 16 KB pieces, as a socket delivers a body stream.write(doc.slice(i, i + 16384)); stream.end(); }); } ```</p> <p>Timing the…</p> https://cve.radiocsirt.org/vuln/ghsa-hqr4-qq8f-hg3x