Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
FlexAssembler, the custom-container assembler shipped in the stream-json package (src/core/utils/flex-assembler.js, re-exported at stream-json/utils/flex-assembler.js and stream-json/web/utils/flex-assembler.js), compiles a string or RegExp path filter into a matcher that runs keyStack.join(separator) on every container start. Because the key stack grows one entry per open object or array with no depth bound, a JSON document nested to depth D drives D container-start tokens that each perform an O(D) join, for O(D^2) total CPU on the single-threaded event loop. An unauthenticated party who can supply JSON bytes to a pipeline that uses a FlexAssembler with a string or RegExp rule filter can stall the process with a small input: roughly 96 KB (depth 16000) blocks the event loop for over a second, and the cost grows quadratically. Root Cause FlexAssembler reconstructs JavaScript values from the parser token stream and supports custom containers selected by path-matching rules.…
Recommended action: Upgrade to 3.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 Timing the pipeline (Node 22, one core, clean install): a 2 MB comment blocks the event…
Recommended action: Upgrade to 3.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A prototype-pollution vulnerability in stream-json lets attacker-controlled JSON replace a parsed object's prototype. Details The streaming JSON parser (StreamValues/StreamObject/jsonc variants) writes keys via plain assignment, so a proto key replaces the parsed object's prototype with attacker-controlled content (verified 3.5.0 npm latest; native JSON.parse twin control stays clean). Parsing untrusted JSON is the contract. Assembler in Assembler.js. PoC Run: Full proof-of-concept source (poc-stream-json-proto-injection.mjs): Observed output (verbatim, Node 24.15.0, Windows): Impact Prototype pollution (CWE-1321). Applications parsing attacker-influenced streaming JSON can have authorization checks read attacker-controlled values. Affects stream-json <= 3.5.0; no patched version exists. --- Maintainer note on scope The attack vector is local — stream-json's documented input is data the user owns (database dumps, exports, logs); it is not designed for JSON from the open…
Recommended action: Upgrade to 3.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The path filters pick, ignore, filter, and replace — the library's headline "surgical extraction" feature — recompute the full path string from the nesting stack on every checkable token. Because the stack length equals the current nesting depth, and a checkable token is emitted at every level, processing a document of depth D costs O(D²), not O(D). This is triggered by document structure (nesting depth), not byte volume, so a tiny payload achieves outsized CPU cost, and it is the ordinary "traverse until the filter matches" path — including the exact README flagship example pick({filter: 'data'}). Any service that uses these filters to extract a field from an untrusted (or larger-than-memory) JSON body — the primary documented use case — can be made to block its event loop. Affected code (v3.4.0) src/core/filters/filter-base.js: stack is pushed/popped on startObject/startArray/end (L239-250), so stack.length === depth. For a depth-D document that hasn't matched yet,…
Recommended action: Upgrade to 3.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.