CVE-2026-104182

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.

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.