Cloudanix VulnDB

CVE-2026-73643

High · 7.5

CVSS

7.5

EPSS

0.5%

Published

Aug 13, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A small specially crafted file can make certain applications using a common configuration format parser freeze and stop responding, interrupting normal operations until fixed.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
Library
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Parsing a crafted small YAML document triggers repeated restoreState and parseNode calls inside readFlowCollection when a flow-sequence entry is treated as a key:value pair, producing O(2^n) CPU work that blocks the Node.js event loop.

Why it matters to the business

Services that accept untrusted YAML input can be rendered unresponsive for minutes by documents under 200 bytes, causing operational outages and service degradation across dependent Red Hat packaged applications until the process is restarted.

How an attack unfolds

An attacker crafts a compact nested flow-sequence YAML that matches the vulnerable parser path, submits it to any load() or loadAll() call on untrusted data, and forces the single-threaded Node.js process into prolonged CPU-bound parsing that stalls all other work.

How to fix it

Upgrade js-yaml to 5.2.2 or later. Red Hat customers should apply the corresponding errata: portal-rhel9:1788943531, pf6-rhel9:1787597578, ui-rhel9:1788206196, plugin-rhel9:1787837308, dashboard-rhel9:1788312226, registry-rhel9:1788312157, or py312-rhel9:1787801527 as listed in RHSA-2026:65126 for each affected product.

How to confirm the fix worked

Confirm js-yaml version is 5.2.2 or newer in package manifests and node_modules; re-test parsing of known exponential YAML samples to verify linear-time behavior; review application dependency trees for remaining vulnerable transitive copies.

Typical attack path

  1. Locate an application endpoint or API that invokes js-yaml load() or loadAll() on externally supplied YAML
  2. Generate a minimal nested flow-sequence document that triggers repeated parseNode recursion
  3. Transmit the payload in a single request or file upload
  4. Observe sustained high CPU and blocked event loop on the target process

How to detect it

Review web-server and application logs for sudden spikes in CPU or request processing time on YAML ingestion endpoints; correlate with unusually small inbound YAML payloads; inspect Node.js process dumps or profiler output for repeated parser recursion stacks.

What your security team should do

  • Immediately update all direct and transitive uses of js-yaml to the fixed versions supplied in RHSA-2026:65126
  • Add input-size and complexity limits or sandboxed parsing workers for any remaining YAML ingestion paths
  • Monitor CPU utilization and event-loop lag metrics on Node.js services handling YAML
  • Prioritize patching of internet-facing or multi-tenant services first given the low attack complexity

The record

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.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities