Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.2",
  "pubDate": "2026-09-03T21:17:21.660Z",
  "pubdate": "2026-09-03T21:17:21.660Z",
  "executiveSummary": "The stream-json library is susceptible to an algorithmic complexity vulnerability stemming from inefficient path processing in its filter-base component.\nThe vulnerability allows an attacker to trigger a Denial of Service (DoS) by submitting a deeply nested JSON document to applications using affected filter components.\nImpact includes the blocking of the Node.js event loop, rendering the application unresponsive to legitimate traffic.\nAffected products include stream-json versions prior to 3.5.0, specifically the pick, ignore, filter, and replace components located in src/core/filters/filter-base.js.\nThe exploitation does not require authentication or elevated privileges, as it is triggered by the structural depth of the provided JSON payload rather than its total byte volume.\nRisk is significant for systems that process untrusted or user-supplied JSON data via these specific filters, as a relatively small, deeply nested payload can disproportionately consume CPU resources and exhaust the event loop cycle.",
  "technicalDetails": "The vulnerability resides in the path filter implementation within src/core/filters/filter-base.js. The root cause is an inefficient recomputation of the full path string derived from the current nesting stack for every checkable token processed by the library.\nDuring normal operation, the library maintains a nesting stack to track the depth of the JSON structure. In affected versions, every time a checkable token is emitted—which occurs at every depth level—the filter mechanism performs a full re-serialization or re-construction of the path string based on the stack depth.\nThis design results in an O(D²) time complexity relative to the document depth D, whereas a constant-time or linear-time approach would ideally result in O(D) complexity.\nExploitation occurs when an attacker provides a maliciously crafted, deeply nested JSON document. Because the event loop in Node.js is single-threaded, the O(D²) computational overhead incurred by the path recomputation blocks the execution of other asynchronous operations.\nAs the depth of the nesting increases, the processing time required for the path string generation grows quadratically. This allows a small payload in terms of bytes to cause a disproportionately high CPU load. The attack is effective even when using the pick({filter: 'data'}) traversal-until-match path configuration.\nThe affected components include the pick, ignore, filter, and replace filters. Notably, the streamArray, streamObject, and streamValues streamers remain unaffected by this flaw because they utilize a more efficient asm.depth getter that operates in constant time.\nThis vulnerability does not require authentication or specific user privileges. The exploitation is triggered simply by the parsing of the malicious document by an application utilizing the vulnerable filter chain. The impact is a complete denial of service for the instance, as the Node.js event loop remains pinned until the processing cycle completes or the process is terminated due to unresponsiveness."
}