GHSA-hqr4-qq8f-hg3x stream-json: JSONC parser and verifier re-scan the whole accumulated comment on every input chunk

• npm stream-json: < 3.6.0 → fixed in 3.6.0

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.