CVE-2026-73643
js-yaml: Exponential parsing time in the flow collections leads to denial of service
CVE-2026-73643 is a high vulnerability (CVSS 7.5) in Nodeca Js-yaml, published July 24, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.49%, the 42nd percentile. Fixed in js-yaml 5.2.2.
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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Exploit likelihood
What each source reports
CVE List Score used
7.5
js-yaml: Exponential parsing time in the flow collections leads to denial of service
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.
- Record
CVE-2026-73643- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Weakness
- CWE-407
- Updated
- 2026-11-02
EUVDEUVD-2026-58185
7.5
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.
- Record
EUVD-2026-58185- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-pm4m-ph32-ghv5
7.5
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.
- Record
GHSA-pm4m-ph32-ghv5- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Weakness
- CWE-407
- Updated
- 2026-11-02
GitHub AdvisoriesGHSA-r3ph-w7gj-g6xm
5.3
js-yaml: maxTotalMergeKeys does not limit CPU use for empty merge sources
Summary
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
arr: &arr [{}, {}, {}, ...] # N empty mappings
targets:
- <<: *arr # repeated K times
For every target, the loader iterates all N elements of arr. This results in O(N * K) work while totalMergeKeys remains unchanged.
PoC
import { performance } from 'node:perf_hooks'
import { load, YAML11_SCHEMA } from 'js-yaml'
const n = 20000
const src =
'arr: &arr [' + '{},'.repeat(n).slice(0, -1) + ']\n' +
'targets:\n' +
' - <<: *arr\n'.repeat(n)
const started = performance.now()
load(src, { schema: YAML11_SCHEMA })
console.log(`${(performance.now() - started).toFixed(1)} ms`)
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.
- Record
GHSA-r3ph-w7gj-g6xm- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - Weakness
- CWE-400, CWE-407
- Updated
- 2026-11-02
NVD
7.5
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.
- Record
CVE-2026-73643- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Weakness
- CWE-407
- Updated
- 2026-11-02
OSV
7.5
js-yaml: Exponential parsing time in the flow collections leads to denial of service
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.
- Record
CVE-2026-73643- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Weakness
- CWE-407
- Updated
- 2026-11-02
Show 10 moreShow less
OSVGHSA-pm4m-ph32-ghv5
7.5
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.
- Record
GHSA-pm4m-ph32-ghv5- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Weakness
- CWE-407
- Updated
- 2026-11-02
OSVGHSA-r3ph-w7gj-g6xm
5.3
js-yaml: maxTotalMergeKeys does not limit CPU use for empty merge sources
Summary
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
arr: &arr [{}, {}, {}, ...] # N empty mappings
targets:
- <<: *arr # repeated K times
For every target, the loader iterates all N elements of arr. This results in O(N * K) work while totalMergeKeys remains unchanged.
PoC
import { performance } from 'node:perf_hooks'
import { load, YAML11_SCHEMA } from 'js-yaml'
const n = 20000
const src =
'arr: &arr [' + '{},'.repeat(n).slice(0, -1) + ']\n' +
'targets:\n' +
' - <<: *arr\n'.repeat(n)
const started = performance.now()
load(src, { schema: YAML11_SCHEMA })
console.log(`${(performance.now() - started).toFixed(1)} ms`)
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.
- Record
GHSA-r3ph-w7gj-g6xm- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - Weakness
- CWE-400, CWE-407
- Updated
- 2026-11-02
OSVUBUNTU-CVE-2026-73643
7.5
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.
- Record
UBUNTU-CVE-2026-73643- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Updated
- 2026-11-02
OSVCLSA-2026-1790718968 No score
TuxCare security update for js-yaml (1 CVE)
TuxCare rebuilt js-yaml to address 1 CVE. Fixed in 5.4.0-tuxcare.1.
- Record
CLSA-2026-1790718968- Updated
- 2026-11-02
OSVCLSA-2026-1792473143 No score
TuxCare security update for js-yaml (2 CVEs)
TuxCare rebuilt js-yaml to address 2 CVEs. Fixed in 5.2.0-tuxcare.1.
- Record
CLSA-2026-1792473143- Updated
- 2026-11-02
OSVCLSA-2026-1792473248 No score
TuxCare security update for js-yaml (2 CVEs)
TuxCare rebuilt js-yaml to address 2 CVEs. Fixed in 5.2.1-tuxcare.1.
- Record
CLSA-2026-1792473248- Updated
- 2026-11-02
OSVCLSA-2026-1792486297 No score
TuxCare security update for js-yaml (1 CVE)
TuxCare rebuilt js-yaml to address 1 CVE. Fixed in 5.2.0-tuxcare.2.
- Record
CLSA-2026-1792486297- Updated
- 2026-11-02
OSVCLSA-2026-1793302102 No score
TuxCare security update for js-yaml (1 CVE)
TuxCare rebuilt js-yaml to address 1 CVE. Fixed in 5.2.2-tuxcare.1.
- Record
CLSA-2026-1793302102- Updated
- 2026-11-02
OSVROOT-APP-NPM-CVE-2026-73643 No score
CVE-2026-73643 in js-yaml - Patched by Root
Root has patched CVE-2026-73643 in the js-yaml package for Root:npm. Multiple fixed versions available.
- Record
ROOT-APP-NPM-CVE-2026-73643- Updated
- 2026-11-02
OSVROOT-APP-NPM-GHSA-pm4m-ph32-ghv5 No score
GHSA-pm4m-ph32-ghv5 in js-yaml - Patched by Root
Root has patched GHSA-pm4m-ph32-ghv5 in the js-yaml package for Root:npm. Multiple fixed versions available.
- Record
ROOT-APP-NPM-GHSA-pm4m-ph32-ghv5- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
js-yamlnpm |
5.0.0 to 5.2.1 | 5.2.2 |
js-yamlnpm |
5.0.0 to 5.4.0 | 5.4.1 |
js-yamlTuxCare:npm |
5.4.0-tuxcare.0 up to 5.4.0-tuxcare.1, plus listed versions 5.4.0 |
5.4.0-tuxcare.1 |
js-yamlTuxCare:npm |
5.2.0-tuxcare.0 up to 5.2.0-tuxcare.1, plus listed versions 5.2.0 |
5.2.0-tuxcare.1 |
js-yamlTuxCare:npm |
5.2.1-tuxcare.0 up to 5.2.1-tuxcare.1, plus listed versions 5.2.1 |
5.2.1-tuxcare.1 |
js-yamlTuxCare:npm |
5.2.0-tuxcare.0 up to 5.2.0-tuxcare.2, plus listed versions 5.2.05.2.0-tuxcare.1 |
5.2.0-tuxcare.2 |
js-yamlTuxCare:npm |
5.2.2-tuxcare.0 up to 5.2.2-tuxcare.1, plus listed versions 5.2.2 |
5.2.2-tuxcare.1 |
js-yamlnpm |
5.0.0 up to 5.2.2 | 5.2.2 |
js-yamlnpm |
5.0.0 up to 5.4.1 | 5.4.1 |
js-yamlRoot:npm |
before 5.2.1-aikido.1 | 5.2.1-aikido.1 |
Show 7 moreShow less
| Package | Affected | Fixed |
|---|---|---|
@rootio/js-yamlRoot:npm |
before 5.2.1-root.io.1 | 5.2.1-root.io.1 |
node-js-yamlUbuntu:18.04:LTS |
All versions, plus listed versions 3.9.1+dfsg-13.10.0+dfsg-1 |
None known |
node-js-yamlUbuntu:20.04:LTS |
All versions, plus listed versions 3.13.1+dfsg-2 |
None known |
node-js-yamlUbuntu:22.04:LTS |
All versions, plus listed versions 3.14.1+dfsg+~3.12.6-24.1.0+dfsg+~4.0.5-4ubuntu14.1.0+dfsg+~4.0.5-54.1.0+dfsg+~4.0.5-6 |
None known |
node-js-yamlUbuntu:24.04:LTS |
All versions, plus listed versions 4.1.0+dfsg+~4.0.5-7 |
None known |
node-js-yamlUbuntu:26.10 |
All versions, plus listed versions 4.1.1+dfsg+~4.0.9-14.2.0+~4.0.9-14.2.0+~4.0.9-2 |
None known |
node-js-yamlUbuntu:26.04:LTS |
All versions, plus listed versions 4.1.0+dfsg+~4.0.5-74.1.1+dfsg+~4.0.9-1 |
None known |
History
| When | Changed | Sources |
|---|---|---|
| 2026-11-02 | created | CVE List, EUVD, GitHub Advisories, NVD, OSV |
References
github.com/nodeca/js-yaml/security/advisories/GHSA-pm4m-ph32-ghv5
github.com/nodeca/js-yaml/commit/3e5240f9cbe645ce5afb58524954a13c8539c853
github.com/nodeca/js-yaml/releases/tag/5.2.2
github.com/advisories/GHSA-pm4m-ph32-ghv5
github.com/nodeca/js-yaml/security/advisories/GHSA-r3ph-w7gj-g6xm
github.com/nodeca/js-yaml/commit/6a8e05f9a485188ed730ac81e81ae221352ef480