How severe is GHSA-pm4m-ph32-ghv5?

GHSA-pm4m-ph32-ghv5 has a CVSS score of 7.5/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-pm4m-ph32-ghv5?

GHSA-pm4m-ph32-ghv5 affects the following packages: js-yaml (npm). Ecosystems affected: npm.

How do I fix GHSA-pm4m-ph32-ghv5?

Update js-yaml to 5.2.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pm4m-ph32-ghv5 is resolved across your whole dependency graph.

How do I detect GHSA-pm4m-ph32-ghv5 in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for js-yaml. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-pm4m-ph32-ghv5 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-pm4m-ph32-ghv5?

O3 pinpoints whether GHSA-pm4m-ph32-ghv5 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-pm4m-ph32-ghv5 actively exploited in the wild?

No public exploit code has been indexed for GHSA-pm4m-ph32-ghv5 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-pm4m-ph32-ghv5 published, and has it been updated?

GHSA-pm4m-ph32-ghv5 was published on July 24, 2026 and was last updated on July 24, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 npm

GHSA-pm4m-ph32-ghv5

HIGH

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

Published

Jul 24, 2026

Updated

Jul 24, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

📦js-yaml

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.

Description

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.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`js-yaml`	≥ 5.0.0&&< 5.2.2	5.2.2

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for js-yaml. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update js-yaml to 5.2.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pm4m-ph32-ghv5 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-pm4m-ph32-ghv5 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-pm4m-ph32-ghv5. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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, pot

O3 Security · Impact-Aware SCA

Is GHSA-pm4m-ph32-ghv5 in your dependencies?

O3 detects GHSA-pm4m-ph32-ghv5 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works