GHSA-hqr4-qq8f-hg3x

## Summary 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's opening `/` on every input chunk. When a comment doesn't finish inside the current buffer, the scanner returns the comment'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. 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's a different code path though — the comment scanner in `handleComment`, which the 3.5.0 depth cap doesn't touch — so upgrading past that advisory doesn'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. ## Proof of concept ``` npm i [email protected] ``` ```js import Parser from 'stream-json/jsonc/parser.js'; function feed(N) { return new Promise(resolve => { const stream = Parser.asStream(); // default options stream.on('data', () => {}); stream.on('error', () => {}); stream.on('end', resolve); const doc = '/*' + 'a'.repeat(N) + '*/1'; // one valid, closed comment for (let i = 0; i < doc.length; i += 16384) // 16 KB pieces, as a socket delivers a body stream.write(doc.slice(i, i + 16384)); stream.end(); }); } ``` Timing the pipeline (Node 22, one core, clean install): a 2 MB comment blocks the event loop ~0.9 s, 4 MB ~2.9 s, 8 MB ~13 s — roughly 4x per doubling, so quadratic. Smaller chunks make it worse, and the attacker controls TCP segment size: a fixed 4 MB comment takes ~0.75 s at 64 KB chunks, ~2.8 s at 16 KB, ~11 s at 4 KB. Feeding the same input to the JSONC verifier reproduces it identically. ## Impact Remote, unauthenticated CPU denial of service against any service that runs untrusted input through the JSONC parser or verifier: one request pins a core and stalls the whole event loop. ## Caveat Only the JSONC entry points are affected; an app on the default JSON parser is safe. The comment doesn't need to be malformed - a valid, properly closed comment does it. The payload is a few MB, or less if the client sends small chunks. I've suggested medium and left the CVSS vector to you. --- # Maintainer note on scope The attack vector is local — stream-json's documented input is data the user owns (JSONC is configuration you wrote); it is not designed for input from the open internet, and the docs now say so explicitly for JSONC. Comments now mirror chunked strings (`startComment` / `commentChunk` / `endComment`, packed `commentValue`); the scan resumes across input chunks, so a comment of any length costs linear time, and constant memory without packing.