Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
maxTotalMergeKeys does not count empty mappings. An attacker can repeatedly merge a large sequence of them and consume significant CPU without reaching the configured limit. Example For every target, the loader iterates all N elements of arr. This results in O(N K) work while totalMergeKeys remains unchanged. PoC Observed results: | N | YAML size | Time | |---:|---:|---:| | 800 | ~13 KB | ~20 ms | | 3200 | ~50 KB | ~180 ms | | 20000 | ~500 KB | ~13 s | Impact When merge keys are enabled, an attacker can submit a relatively small YAML document that causes prolonged CPU consumption despite the default maxTotalMergeKeys limit. Fix Count every merge source mapping as one budget unit in addition to counting its keys.
Recommended action: Upgrade to 5.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
maxTotalMergeKeys does not count empty mappings. An attacker can repeatedly merge a large sequence of them and consume significant CPU without reaching the configured limit. Example For every target, the loader iterates all N elements of arr. This results in O(N K) work while totalMergeKeys remains unchanged. PoC Observed results: | N | YAML size | Time | |---:|---:|---:| | 800 | ~13 KB | ~20 ms | | 3200 | ~50 KB | ~180 ms | | 20000 | ~500 KB | ~13 s | Impact An attacker can submit a relatively small YAML document that causes prolonged CPU consumption despite the default maxTotalMergeKeys limit. Fix Count each merge-source mapping as one budget unit, in addition to counting its keys. Difference with v5 In v3 & v4, merge is enabled by default. So, the severity score is higher.
Recommended action: Upgrade to 4.3.2 or 3.15.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.3.1 or 3.15.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 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…
Recommended action: Upgrade to 5.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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) 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.
Recommended action: Upgrade to 5.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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) 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.
Recommended action: Upgrade to 4.3.0 or 3.15.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
js-yaml v5.x introduces YAML11SCHEMA 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.YAML11SCHEMA }. Details In src/tag/sequence/omap.ts (compiled: dist/js-yaml.cjs.js:510-525): 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) Impact Any application that parses untrusted YAML using yaml.load(input, { schema: yaml.YAML11SCHEMA }) 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…
Recommended action: Upgrade to 5.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.2.0 or 3.15.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/PrototypePollutionPreventionCheatSheet.html
Recommended action: Upgrade to 4.1.1 or 3.14.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of js-yaml prior to 3.13.0 are vulnerable to Denial of Service. By parsing a carefully-crafted YAML file, the node process stalls and may exhaust system resources leading to a Denial of Service. Recommendation Upgrade to version 3.13.0.
Recommended action: Upgrade to 3.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of js-yaml prior to 3.13.1 are vulnerable to Code Injection. The load() function may execute arbitrary code injected through a malicious YAML file. Objects that have toString as key, JavaScript code as value and are used as explicit mapping keys allow attackers to execute the supplied code through the load() function. The safeLoad() function is unaffected. An example payload is { toString: !<tag:yaml.org,2002:js/function 'function (){return Date.now()}' } : 1 which returns the object { "1553107949161": 1 } Recommendation Upgrade to version 3.13.1.
Recommended action: Upgrade to 3.13.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions 2.0.4 and earlier of js-yaml are affected by a code execution vulnerability in the YAML deserializer. Proof of Concept Recommendation Update js-yaml to version 2.0.5 or later, and ensure that all instances where the .load() method is called are updated to use .safeLoad() instead.
Recommended action: Upgrade to 2.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.