stream-json: JSONC parser and verifier re-scan the whole accumulated comment on every input chunkGHSA-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]

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.