Threat database

## Summary `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. When a rule `filter` is a string or RegExp, `compileFilter` returns a matcher that computes the joined path from the full key stack before making any match decision. That join is O(current depth), and it is invoked unconditionally for every rule on every container start. The key stack that feeds the join has no depth cap. The package does have a depth guard (`maxDepth`), but it exists only in the unrelated filter base state machine and never executes on the `FlexAssembler` code path, so nested input is unbounded here. ```text src/core/utils/flex-assembler.js compileFilter (lines 5-21): string branch computes `path.join(separator)` (line 10) before the `=== filter || startsWith(...)` comparison; RegExp branch computes `filter.test(path.join(separator))` (line 17). The join runs first, unconditionally. FlexAssembler._matchRule (lines 160-166): calls `rule.filter(this.keyStack)` for every rule; invoked from startObject (line 184) and startArray (line 197) on every container start. FlexAssembler._pushState (lines 168-176): pushes one entry onto `keyStack` per open container with no depth bound. ``` ## Impact An attacker who can deliver JSON to a pipeline whose `FlexAssembler` is configured with a string or RegExp rule filter (a documented, tested, first-class option: `Filter = string | RegExp | FilterFunction`) can cause quadratic CPU consumption. The join runs regardless of whether the rule ultimately matches, so no attacker knowledge of the schema is required beyond nesting depth, which the attacker fully controls. The demonstrated capability is an availability impact: a small crafted document blocks the Node.js event loop, stalling all concurrent work on the process. There is no confidentiality or integrity impact. A consumer that uses only a function filter or no rules is not affected, which narrows the vulnerable population but does not raise attack complexity once such a configuration is in use. ## Proof of Concept `Node.js and the published stream-json@3.6.0 package. Drive a FlexAssembler configured with a string rule filter, comparing against a function filter as a negative control.` 1. Install `stream-json@3.6.0`. 2. Construct a deeply nested object token stream (or equivalently parse a document like `'{"k":'` repeated D times, a `1`, then `'}'` repeated D times, through `parser`/`parserStream`). 3. Feed it to a `FlexAssembler` whose `objectRules` contains a rule with a string `filter`. 4. Observe wall-clock time scaling as roughly 4x per doubling of D (quadratic), while a function-filter configuration stays flat. ```js import FlexAssembler from 'stream-json/utils/flex-assembler.js'; function run(filter, D) { const asm = new FlexAssembler(filter ? {objectRules: [{filter, create: () => ({})}]} : undefined); const t = performance.now(); asm.startObject(); for (let i = 0; i < D; i++) { asm.keyValue('k'); asm.startObject(); } return performance.now() - t; } for (const D of [4000, 8000, 16000, 32000]) console.log('string', D, run('k', D).toFixed(1), 'ms'); for (const D of [4000, 8000, 16000, 32000]) console.log('function(control)', D, run(p => p.length > 0, D).toFixed(1), 'ms'); ``` ```text string filter (path.join per token): function filter (negative control, no join): D=4000 91.9 ms D=4000 1.6 ms D=8000 341.9 ms D=8000 0.9 ms D=16000 1359.2 ms (~4x per doubling) D=16000 1.7 ms (flat) D=32000 5430.0 ms (= O(D^2)) D=32000 2.6 ms ``` End to end through a real `parserStream`, roughly 96 KB (depth 16000) of attacker-supplied JSON stalls the event loop for over 1.3 seconds. ## Attack Chain 1. **Exposure:** The attacker supplies JSON bytes to a service pipeline that assembles values with a `FlexAssembler` configured with a string or RegExp rule filter; `FlexAssembler` is a documented submodule of the published package on both the Node and Web Streams surfaces. 2.

CVE-2026-104183 is a prototype pollution vulnerability in the uhop stream-json library prior to version 3.6.0. The vulnerability arises because the Assembler component assigns object properties using plain assignment, allowing an input key named __proto__ to modify the prototype of parsed objects. This can lead to attacker-controlled inherited properties affecting application logic that relies on prototype values. The global Object.prototype is not affected. The issue is fixed in version 3.6.0.

CVE-2026-104182 is an inefficient algorithmic complexity vulnerability in the JSONC parser and verifier components of the uhop stream-json library prior to version 3.6.0. The issue arises when processing large valid comments split across many small input chunks, causing quadratic CPU usage and potentially stalling the Node.js event loop. This vulnerability affects only the JSONC parser, not the plain JSON parser. The maintainer notes the attack vector is local, involving user-controlled or locally owned configuration input rather than internet-facing input. The issue is fixed in version 3.6.0.

stream-json is a micro-library of stream components for processing JSON and JSONC with a minimal memory footprint. Prior to 3.5.0, the path filters pick, ignore, filter, and replace in src/core/filters/filter-base.js recompute the full path string from the nesting stack for every checkable token. Because the stack length equals the current nesting depth and a checkable token is emitted at every level, a depth D document costs O(D²) rather than O(D) to process. The issue is triggered by nesting depth rather than byte volume, including the documented pick({filter: 'data'}) traversal-until-match path, so an application that sends untrusted JSON through a string or RegExp filter can block the Node.js event loop and cause denial of service with a small deeply nested document. The streamArray, streamObject, and streamValues streamers are not affected because they use the constant-time asm.depth getter. This issue is fixed in version 3.5.0.

node-re2 provides RE2 regular expression bindings for Node.js. Prior to version 1.26.1, passing a Buffer whose final bytes form a truncated (incomplete) multi-byte UTF-8 sequence could cause the native binding to read past the end of the allocated buffer while attempting to decode the final, incomplete code point. This could result in an out-of-bounds read and potential disclosure of adjacent memory contents. This issue is fixed in version 1.26.1.

node-re2 provides RE2 regular expression bindings for Node.js. Prior to version 1.25.1, the WrappedRE2::Replace function built its replacement result and passed it to V8 using ToLocalChecked without checking for the empty MaybeLocal that V8 returns when the resulting string or buffer exceeds V8's maximum string length. When a global replace uses an output amplifying replacement template, the result can grow quadratically with the input size, and once the result exceeds V8's maximum string length, the unchecked ToLocalChecked call causes a fatal, uncatchable process abort instead of a catchable exception. This issue is fixed in version 1.25.1.

CVE-2026-68499 is a vulnerability in the node-re2 package, which provides Node.js bindings for Google's RE2 regular expression engine. Versions prior to 1.25.2 have a flaw in the String.prototype.match implementation when using a global RE2 pattern that can match the empty string. This causes an infinite loop due to failure to advance the matching cursor, leading to unbounded native memory growth, blocking the event loop and potentially exhausting host memory. The issue is fixed in version 1.25.2.

re2 provides Node.js bindings for Google's RE2 regular expression engine. Prior to 1.25.2, re2 validates lastIndex against the UTF-8 byte length of a subject but uses it as a UTF-16 code-unit offset in exec, test, match, replace, and split, allowing an attacker-influenced lastIndex on a non-ASCII subject to trigger an out-of-bounds heap read and an uncatchable process crash, with limited heap information disclosure in some cases. This issue is fixed in 1.25.2.