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

depfu · 2026-07-30T23:10:40Z

🚨 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 upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

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

Security Advisories 🚨

🚨 js-yaml: Exponential parsing time in flow collections leads to denial of service

Summary

Parsing a small YAML document can take exponential time. An application that calls load() or loadAll() on untrusted input can be hung by a payload under 200 bytes.

Details

When an entry in a flow sequence turns out to be a key: value pair, the parser rewinds and parses that entry a second time as the key.
If the key is itself a nested flow sequence of the same shape, every level is parsed twice, so the total work is O(2^n) in the nesting depth. The default maxDepth of 100 does not help, because the time is already unmanageable at about 30 to 40 levels.

Root cause, potentially the: readFlowCollection in parser.ts, the restoreState followed by a second parseNode further down.

PoC
const yaml = require('js-yaml')
const n = 30
yaml.load('[ '.repeat(n) + '1' + ' ]: 0'.repeat(n))
With default options: 22 levels takes about 1 second, 26 levels about 17 seconds, 30 levels over 2 minutes. The input stays under 200 bytes and grows linearly with n.

Impact

Denial of service. A single small request can keep one CPU busy for minutes or longer and blocks the Node event loop, so one request can stall the whole process. No anchors, aliases, merges, tags, or non default options are required, and it reproduces on the default schema.

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

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<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 (O(n^2)) DoS via !!omap tag in YAML11_SCHEMA

Summary

js-yaml v5.x introduces YAML11_SCHEMA support with the !!omap (ordered map) tag. The omapTag.addItem() function performs a linear O(n) scan for duplicate key detection on every insertion, resulting in O(n^2) total time to parse a document with n omap entries. An attacker can send a small crafted YAML document to trigger a multi-second CPU stall in any application that uses yaml.load() with { schema: yaml.YAML11_SCHEMA }.

Details

In src/tag/sequence/omap.ts (compiled: dist/js-yaml.cjs.js:510-525):
var omapTag = defineSequenceTag('tag:yaml.org,2002:omap', {
    create: () => [],
    addItem: (container, item) => {
        // ...
        for (const existing of container)   // O(n) per insertion!
            if (hasOwnProperty(existing, itemKeys[0]))
                return 'cannot resolve an ordered map item';
        container.push(object);             // n insertions → O(n^2) total
        return '';
    }
});
For a document with n unique entries, insertion i scans i−1 existing entries, yielding 1+2+…+n = O(n²) total work.

PoC (runtime-confirmed on v5.2.0)
const yaml = require('js-yaml');
function buildOmapPayload(n) {
  let p = '!!omap\n';
  for (let i = 0; i < n; i++) p += '- key' + i + ': val' + i + '\n';
  return p;
}
// Timing results on v5.2.0:
// n=1000:  9ms
// n=5000:  73ms  (5x n → 8x time)
// n=10000: 255ms (2x n → 3.5x time — supralinear)
// n=20000: 997ms (2x n → 3.9x time — O(n²) confirmed)
// n=50000: 10613ms          ← blocks event loop for >10 seconds
yaml.load(buildOmapPayload(50000), { schema: yaml.YAML11_SCHEMA });
Impact

Any application that parses untrusted YAML using yaml.load(input, { schema: yaml.YAML11_SCHEMA }) is vulnerable to Denial of Service. A ~2 MB payload of 50,000 entries blocks the Node.js event loop for 10+ seconds. Smaller payloads (5,000 entries, ~100 KB) already cause noticeable slowdowns (73 ms per parse, amplified under concurrent load).

This affects the newly released 5.x series (first published 2026-06-20) which adds YAML 1.1/1.2 schema support including !!omap. The 4.x series is unaffected (no YAML11_SCHEMA export).

Fix

Replace the O(n) linear scan in addItem with an O(1) Set-based lookup:
var omapTag = defineSequenceTag('tag:yaml.org,2002:omap', {
    create: () => ({ list: [], seen: new Set() }),
    addItem: (state, item) => {
        const key = Object.keys(item)[0];
        if (state.seen.has(key)) return 'duplicate omap key';
        state.seen.add(key);
        state.list.push(item);
        return '';
    },
    resolve: (state) => state.list
});

🚨 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

5.2.2 (from changelog)

Fixed

Quote flow scalars where a colon precedes a flow indicator, #773.

Security

Avoid exponential parsing time for nested flow sequence pairs.

5.2.1 (from changelog)

Fixed

Add Map support to !!omap (should work when realMapTag used)

Security

Remove quadratic complexity from !!omap addItem. Regression from v5 (usually not critical, because YAML11_SCHEMA is not default anymore).

5.2.0 (from changelog)

Added

Added maxTotalMergeKeys (10000) loader option to limit the total number of keys processed by YAML merge (<<) across one load() / loadAll() call.

Added maxAliases (-1) loader option to limit the number of YAML aliases per document.

Removed

maxMergeSeqLength replaced with maxTotalMergeKeys for limiting YAML merge processing.

Fixed

Round-trip of integers with exponential form (>= 1e21)

5.1.0 (from changelog)

Added

Collection tags can finalize an incrementally populated carrier into a different result value.

Changed

[breaking] quoteStyle now selects the preferred quote style; use the restored forceQuotes option to force quoting non-key strings.

5.0.0 (from changelog)

Added

Added named exports for schemas, tags, parser events and AST utilities.

Reworked JSON_SCHEMA and CORE_SCHEMA with spec-compliant scalar resolution rules, and added YAML11_SCHEMA.

Added realMapTag for lossless mappings with non-string and complex keys. Object-based mappings now reject complex keys instead of stringifying them.

Added dump() transform option for changing the generated AST before rendering.

Added dump() options seqInlineFirst, flowBracketPadding, flowSkipCommaSpace, flowSkipColonSpace, quoteFlowKeys, quoteStyle and tagBeforeAnchor.

Added formal data layers (events and AST) for modular data pipelines.

Added low-level parser (to events), presenter and visitor APIs.

Added the YAML Test Suite to the test set.

Changed

See the migration guide for upgrade notes.

Rewritten in TypeScript and reorganized the public API around flat named exports.

Reduced the set of exported schemas:

YAML 1.2 schemas: CORE_SCHEMA (loader default), JSON_SCHEMA, FAILSAFE_SCHEMA.

YAML11_SCHEMA, a combination of all YAML 1.1 tags (YAML 1.1 does not specify a schema, only "types").

load/dump default behaviour is now specified exactly via schemas:

load uses CORE_SCHEMA, without !!merge by default.

dump uses YAML11_SCHEMA + CORE_SCHEMA for the quoting check, to guarantee backward compatibility by default.

!!set is now loaded as a JavaScript Set.

Replaced the Type API with a tags API. Similar, but more precise and simpler. See examples for details. Tags can be defined via defineScalarTag(), defineSequenceTag() and defineMappingTag(), or as a spread + override of an existing tag.

Renamed Schema.extend() to Schema.withTags().

Expanded YAML 1.2 conformance and improved handling of directives, document markers, block keys, multiline scalars, tag syntax and other things.

load() now throws on empty input instead of returning undefined.

Moved browser builds to the js-yaml/browser export.

Deprecated the loadAll signature with an iterator (still works, but is a candidate for removal).

Removed

Removed deprecated safeLoad(), safeLoadAll() and safeDump() exports.

Removed DEFAULT_SCHEMA and the nested types export.

Removed loader options onWarning, legacy and listener.

Removed dumper options styles, replacer, noCompatMode, condenseFlow, quotingType and forceQuotes. Renamed noArrayIndent to seqNoIndent. Formatting and representation are now configured through presenter options, schemas and tag definitions. See migration guide on how to replace.

Removed support for importing internal files from lib/.

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 more commits than we can show here.

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 Jul 30, 2026

depfu Bot temporarily deployed to beta July 30, 2026 23:10 Inactive

depfu Bot mentioned this pull request Jul 30, 2026

🚨 [security] Update js-yaml 4.1.0 → 5.2.1 (major) #570

Closed

Update js-yaml to version 5.2.2

3e4d85c

depfu Bot force-pushed the depfu/update/npm/js-yaml-5.2.2 branch from 281ac55 to 3e4d85c Compare August 15, 2026 19:36

depfu Bot deployed to beta August 15, 2026 19:36 Active

Navigation Menu

Uh oh!

🚨 [security] Update js-yaml 4.1.0 → 5.2.2 (major) - #579

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

depfu Bot commented Jul 30, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Uh oh!

Conversation

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

Uh oh!

What changed?

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

🚨 js-yaml: Exponential parsing time in flow collections leads to denial of service

Summary

Details

PoC

Impact

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

Impact

PoC

Patches

🚨 js-yaml: Quadratic-complexity (O(n^2)) DoS via !!omap tag in YAML11_SCHEMA

Summary

Details

PoC (runtime-confirmed on v5.2.0)

Impact

Fix

🚨 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

5.2.2 (from changelog)

Fixed

Security

5.2.1 (from changelog)

Fixed

Security

5.2.0 (from changelog)

Added

Removed

Fixed

5.1.0 (from changelog)

Added

Changed

5.0.0 (from changelog)

Added

Changed

Removed

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 Jul 30, 2026 •

edited

Loading