Résumé
js-yaml: Exponential parsing time in flow collections leads to denial of service
Détails de l’avis
Summary
Parsing a small YAML document can take exponential time. An application that calls load() or loadAll() on untrusted input can be hung by a payload under 200 bytes.
Details
When an entry in a flow sequence turns out to be a key: value pair, the parser rewinds and parses that entry a second time as the key.
If the key is itself a nested flow sequence of the same shape, every level is parsed twice, so the total work is O(2^n) in the nesting depth. The default maxDepth of 100 does not help, because the time is already unmanageable at about 30 to 40 levels.
Root cause, potentially the: readFlowCollection in parser.ts, the restoreState followed by a second parseNode further down.
PoC
const yaml = require('js-yaml')
const n = 30
yaml.load('[ '.repeat(n) + '1' + ' ]: 0'.repeat(n))
With default options: 22 levels takes about 1 second, 26 levels about 17 seconds, 30 levels over 2 minutes. The input stays under 200 bytes and grows linearly with n.
Impact
Denial of service. A single small request can keep one CPU busy for minutes or longer and blocks the Node event loop, so one request can stall the whole process. No anchors, aliases, merges, tags, or non default options are required, and it reproduces on the default schema.
Références
Vulnérabilités liées
Tout Supply chain →- MEDIUMCVE-2026-71429
stream-json: pick/ignore/filter/replace filters are O(depth²) on nested input — small crafted JSON blocks the event loop for seconds→minutes (DoS)
- MEDIUMCVE-2026-82398
pypdf: Inefficient handling of non-whitespace inputs in read_until_whitespace
- MEDIUMCVE-2026-81722
NLTK: Quadratic-time DoS in PorterStemmer via long runs of 'y'
- MEDIUMCVE-2026-81723
NLTK: Quadratic CPU Exhaustion in `XMLCorpusView._read_xml_fragment()`
- MEDIUMCVE-2026-12876
NLTK: Uncontrolled resource consumption in RecursiveDescentParser via ambiguous or left-recursive grammars
- MEDIUMCVE-2026-84305
sqlparse: Reindentation of tuple lists causes near-cap quadratic CPU consumption