A vulnerability in js-yaml versions 5.0.0 up to but not including 5.4.1 allows an attacker to cause excessive CPU consumption by exploiting how empty merge source mappings are counted. The maxTotalMergeKeys setting does not count empty mappings, enabling an attacker to craft YAML documents that cause the loader to perform O(N*K) work, leading to prolonged CPU usage. This can result in denial of service due to resource exhaustion. A patch is available that adjusts the counting method to include every merge source mapping as one budget unit.
js-yaml is a JavaScript YAML parser and dumper. From 5.0.0 until 5.2.2, parsing a small YAML document can take exponential time when an application calls load() or loadAll() on untrusted input. In src/parser/parser.ts, readFlowCollection uses restoreState and calls parseNode a second time when a flow-sequence entry is recognized as a key: value pair. If the key is a nested flow sequence of the same shape, every level is parsed twice, causing O(2^n) work and allowing an input under 200 bytes to keep one CPU busy for minutes, block the Node.js event loop, and stall the process. No anchors, aliases, merges, tags, or nondefault options are required. This issue is fixed in version 5.2.2.
js-yaml versions 3.x and 4.x contain a quadratic CPU consumption vulnerability in the resolution of the !!omap YAML type. The vulnerability arises from a linear scan to enforce key uniqueness, causing CPU usage to grow quadratically with the number of entries. This can lead to denial of service by blocking the Node.js event loop during YAML parsing of attacker-controlled input. The issue is fixed in js-yaml 5.2.1 by using a Set to track keys, but this fix was not backported to the 3.x and 4.x lines.
js-yaml is a JavaScript YAML parser and dumper. From 5.0.0 before 5.2.0, when merge keys are enabled, js-yaml can spend quadratic CPU time parsing a document whose size grows only linearly when a chain of mappings uses merge keys where each mapping merges the previous one. This issue is fixed in version 5.2.0.
js-yaml is a JavaScript YAML parser and dumper. From 3.0.0 before 3.15.0 and from 4.0.0 before 4.3.0, js-yaml can spend quadratic CPU time parsing a document whose size grows only linearly when a chain of mappings uses merge keys where each mapping merges the previous one. This issue is fixed in versions 3.15.0 and 4.3.0.
js-yaml is a JavaScript YAML parser and dumper. Prior to 3.15.1, 4.3.1, and 5.2.1, YAML11_SCHEMA support for the !!omap tag in src/tag/sequence/omap.ts uses omapTag.addItem() to perform a linear duplicate-key scan on every insertion, causing O(n^2) CPU consumption when yaml.load() parses a crafted ordered-map document. In v3 and v4, !!omap is active and exploitable by default. v5 doesn't use !!omap by default, and the chances of activating it are very low.This issue is fixed in 3.15.1, 4.3.1, and 5.2.1.
js-yaml is a JavaScript YAML parser and dumper. Prior to 4.2.0 and 3.15.0, 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. The issue is in merge handling inside lib/loader.js. This vulnerability is fixed in 4.2.0 and 3.15.0.
js-yaml is a JavaScript YAML parser and dumper. In js-yaml before 4.1.1 and 3.14.2, 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. The problem is patched in js-yaml 4.1.1 and 3.14.2. Users 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).