CVE-2026-114129

CVE-2026-114129 is a medium-severity security vulnerability in stream-json (npm), affecting versions >= 2.0.0, <= 3.6.0. It is fixed in 3.7.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

stream-json: FlexAssembler string/RegExp path filters join the full key stack per container start, giving O(depth^2) CPU denial of service

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.

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.

Proof of Concept

Node.js and the published [email protected] package. Drive a FlexAssembler configured with a string rule filter, comparing against a function filter as a negative control.

  1. Install [email protected].
  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.
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');
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. Control: The attacker controls the JSON bytes and therefore the nesting depth D, which directly controls the key stack length.
  3. Path: Each { or [ emits startObject/startArray, which push onto keyStack and call _matchRule, which calls the compiled filter with the current key stack.
  4. Guard: There is no depth or size cap on this path; the only maxDepth guard in the package lives in the filter base state machine and never runs in FlexAssembler.
  5. Primitive: For each of the D container starts, the compiled string/RegExp filter runs an O(D) join before any match decision, for O(D^2) total CPU.
  6. Result: The single-threaded event loop stalls, denying service to all concurrent work on the process; a small input scales quadratically to sustained unavailability.

Bypass Evidence

This is a novel finding on a code path that no prior fix protects, so there is no guard to bypass on the FlexAssembler path. The relevant prior fix is the maxDepth cap published as part of the remediation for CVE-2026-71429 (GHSA-528h-pc64-c93x), which addressed the analogous O(depth^2) behavior in the pick/ignore/filter/replace filters. That fix was placed only in src/core/filters/filter-base.js; src/core/utils/flex-assembler.js neither imports nor invokes it, so the guard never executes here. A search for maxDepth across src/ returns only the filter base file and its type declaration, and flex-assembler.js imports only {none} from stream-chain/core. Attempts to refute the finding all failed: the join was confirmed to run unconditionally before the match comparison in both the string and RegExp branches; a function-filter negative control stayed flat while the string filter scaled at 4x per doubling, isolating the join as the quadratic cause; and the behavior was reproduced both by driving FlexAssembler directly and end to end through a real parser pipeline. This is not the same issue as the JSONC comment re-scan advisory (GHSA-hqr4-qq8f-hg3x) or the Assembler prototype pollution advisory (GHSA-mjw6-4jj6-33hc), which involve different components, mechanisms, and impact classes.

Affected Versions

  • Ecosystem: npm
  • Package: stream-json
  • Confirmed affected range: >= 2.0.0, <= 3.6.0
  • Latest release checked: 3.6.0 (npm registry latest)
  • Fix status: not fixed

FlexAssembler was introduced in 2.0.0; the 1.x line has no such component. The vulnerable compileFilter join branches, the uncapped key stack, and the absence of any depth guard are present and effectively identical across the 2.0.0 through 3.6.0 releases, including the current registry latest (3.6.0). No fixed release exists: the depth cap shipped for the related filter issue does not touch FlexAssembler, so every release in the range is affected and a future release remains affected until a FlexAssembler-side bound ships.

Maintainer note on scope

The attack vector is local — stream-json's documented input is data the user owns (dumps, exports, logs, configuration you wrote); it is not designed for JSON from the open internet, and the docs say so. The crafted document reaches the vulnerable component as a buffer, so AV:L gives 6.2, the same vector and score as GHSA-528h-pc64-c93x and GHSA-hqr4-qq8f-hg3x. FlexAssembler now takes a maxDepth option, default 1024, which throws a RangeError before any rule is matched; Infinity opts out, and once rules are configured the cap covers containers of both kinds, because a rule's path state is kept at every level whatever kind it matches. A follow-up went past what the advisory needed and removed the per-check join entirely — a string filter keeps prefix-match state per level, a RegExp an accumulated path, a function filter the parts array it already received — so deeply nested input is linear now rather than merely capped.

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.

CVE-2026-114129 has a CVSS score of 6.2 (Medium). The vector is requires local access, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.7.0); upgrading removes the vulnerable code path.

Affected versions

stream-json (>= 2.0.0, <= 3.6.0)

Security releases

stream-json → 3.7.0 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Enforce a nesting depth bound on the FlexAssembler assembly path, mirroring the maxDepth guard already used by the filter base state machine, so that pathologically deep input is rejected before it drives quadratic work. Alternatively, or in addition, eliminate the per-container full-stack join in compileFilter by maintaining the joined path incrementally (append the new segment on push, truncate on pop) or by comparing the key stack against the filter with a prefix walk that is O(1) amortized per container start rather than O(depth). Any fix must cover both the string and RegExp filter branches and both the object and array rule paths, on both the Node and Web Streams surfaces. As an interim mitigation without a code change, consumers can use function filters (which do not perform the join) or impose an upstream input size or depth limit before the parser.

Reported by zx (GitHub: @manus-pi).

Frequently Asked Questions

  1. What is CVE-2026-114129? CVE-2026-114129 is a medium-severity security vulnerability in stream-json (npm), affecting versions >= 2.0.0, <= 3.6.0. It is fixed in 3.7.0.
  2. How severe is CVE-2026-114129? CVE-2026-114129 has a CVSS score of 6.2 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of stream-json are affected by CVE-2026-114129? stream-json (npm) versions >= 2.0.0, <= 3.6.0 is affected.
  4. Is there a fix for CVE-2026-114129? Yes. CVE-2026-114129 is fixed in 3.7.0. Upgrade to this version or later.
  5. Is CVE-2026-114129 exploitable, and should I be worried? Whether CVE-2026-114129 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-114129 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-114129? Upgrade stream-json to 3.7.0 or later.

Other vulnerabilities in stream-json

Stop the waste.
Protect your environment with Kodem.