---
id: "CVE-2026-114129"
kind: "vulnerability"
aliases: ["CVE-2026-114129", "GHSA-jj87-hc4r-jwfw"]
title: "stream-json: FlexAssembler string/RegExp path filters join the full key stack per container start, giving O(depth^2) CPU denial of service"
severity: "medium"
cvss: 6.2
epss: 0.0013699999544769526
exploited: false
status: "open"
category: "package"
products: [{"name": "stream-json", "fixed": ["3.7.0"], "affected": ">= 2.0.0, <= 3.6.0", "ecosystem": "npm"}]
ecosystems: ["npm"]
tags: ["cwe-407", "node.js", "npm", "package", "self-hosted", "stream-json"]
not_affected_if: ["function-filter-only", "no-flexassembler-rules", "stream-json-1.x", "trusted-input-only"]
published_at: "2026-10-21T18:17:25+00:00"
first_seen_at: "2026-10-23T19:11:32+00:00"
updated_at: "2026-10-23T21:57:29+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-jj87-hc4r-jwfw", "first_seen_at": "2026-10-23T19:11:32+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114129", "first_seen_at": "2026-10-23T21:57:29+00:00"}]
---

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

stream-json's FlexAssembler rebuilds the full key path on every container start when a string or RegExp rule filter is configured, so deeply nested JSON costs quadratic CPU and can block the Node.js event loop. An attacker who can supply JSON to such a pipeline can stall the process with a roughly 96 KB document, causing denial of service with no confidentiality or integrity impact.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- npm:stream-json affected >= 2.0.0, <= 3.6.0 fixed 3.7.0

## How to check

Check whether the project depends on stream-json (npm ls stream-json) and whether it imports stream-json/utils/flex-assembler.js or uses FlexAssembler with objectRules/arrayRules using string or RegExp filters.
If so, confirm the installed version is between 2.0.0 and 3.6.0 inclusive.

## Fix

The maintainer note says a follow-up release removes the per-check join and adds a maxDepth option (default 1024, throws RangeError); the exact fixed version is not confirmed in the sources, which list fixed 3.7.0 in products but also say status open.
Interim: use function filters or impose an upstream input size or depth limit before the parser.

## Timeline

- 2026-10-23T19:11:32+00:00 ghsa https://github.com/advisories/GHSA-jj87-hc4r-jwfw
- 2026-10-23T21:57:29+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-114129

## From the sources

## 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. **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.

## Suggested Fix

Enforce a nesting depth bound on the `FlexAssembler` assembly path, mirroring the `ma

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_