<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-26T06:19:58.014767+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-114129</id>
    <title>fkie_cve-2026-114129</title>
    <updated>2026-10-26T06:19:58.032953+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>stream-json is a micro-library of stream components for processing JSON and JSONC with a minimal memory footprint. From 2.0.0 until 3.7.0, FlexAssembler compiles string and regular-expression path filters into matchers that join the full key stack on every container start. Because the key stack grows with unbounded object or array nesting, a document nested to depth D causes D joins whose cost grows with the current depth, resulting in quadratic CPU consumption on the single-threaded event loop. The join occurs before the rule match decision, so the attacker does not need to know the target schema. Consumers using only function filters or no rules are not affected. A crafted nested document can stall all concurrent work in a process that feeds it to an affected FlexAssembler. This issue is fixed in 3.7.0, which adds a default maximum depth.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-114129"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-jj87-hc4r-jwfw</id>
    <title>GHSA-jj87-hc4r-jwfw — stream-json: FlexAssembler string/RegExp path filters join the full key stack per container start, giving O(depth^2) CP…</title>
    <updated>2026-10-26T06:19:58.033034+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: stream-json</p>
<p>## Summary</p>
<p>`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.</p>
<p>## Root Cause</p>
<p>`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…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-jj87-hc4r-jwfw"/>
  </entry>
</feed>
