Skip to content

chore: Update js-yaml to 5.2.2 [SECURITY] - #222

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-js-yaml-vulnerability
Open

chore: Update js-yaml to 5.2.2 [SECURITY]#222
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-js-yaml-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
js-yaml >=4.2.0>=5.2.2 age adoption passing confidence

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

CVE-2026-59870 / GHSA-724g-mxrg-4qvm

More information

Details

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
});

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


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

GHSA-pm4m-ph32-ghv5

More information

Details

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.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


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

CVE-2026-59869 / GHSA-52cp-r559-cp3m

More information

Details

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.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


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

GHSA-5p4m-2wfm-xmqj

More information

Details

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.jsrequire('../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.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Release Notes

nodeca/js-yaml (js-yaml)

v5.2.2

Compare Source

Fixed
  • Quote flow scalars where a colon precedes a flow indicator, #​773.
Security
  • Avoid exponential parsing time for nested flow sequence pairs.

v5.2.1

Compare Source

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

v5.2.0

Compare Source

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)

v5.1.0

Compare Source

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.

v5.0.0

Compare Source

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

v4.3.1

Compare Source

v4.3.0

Compare Source


Configuration

📅 Schedule: (in timezone Asia/Kolkata)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot requested a review from chitrank2050 as a code owner August 8, 2026 18:48
@renovate
renovate Bot enabled auto-merge (squash) August 8, 2026 18:48
@chitrank-actions chitrank-actions Bot added the area/deps Dependency upgrades and lockfile updates label Aug 8, 2026
@renovate renovate Bot changed the title chore: Update js-yaml to 4.3.1 [SECURITY] chore: Update js-yaml to 5.2.2 [SECURITY] Aug 8, 2026
@renovate
renovate Bot force-pushed the renovate/npm-js-yaml-vulnerability branch from cdbf3bc to 4809d45 Compare August 8, 2026 20:53
@renovate renovate Bot changed the title chore: Update js-yaml to 5.2.2 [SECURITY] chore: Update js-yaml to 4.3.1 [SECURITY] Aug 11, 2026
@renovate
renovate Bot force-pushed the renovate/npm-js-yaml-vulnerability branch from 4809d45 to 8c05707 Compare August 11, 2026 22:47
@renovate renovate Bot changed the title chore: Update js-yaml to 4.3.1 [SECURITY] chore: Update js-yaml to 5.2.2 [SECURITY] Aug 12, 2026
@renovate
renovate Bot force-pushed the renovate/npm-js-yaml-vulnerability branch from 8c05707 to cfd2eab Compare August 12, 2026 05:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/deps Dependency upgrades and lockfile updates security vulnerability

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants