CVE-2026-59870: js-yaml Denial-of-Service via Ordered-Map Parsing

Technical summary

The vulnerability exists in src/tag/sequence/omap.ts where the YAML11_SCHEMA implementation uses omapTag.addItem() to scan for duplicate keys during every insertion into an ordered map. This linear O(n²) algorithm becomes computationally expensive when processing YAML documents with large ordered-map structures. An attacker can craft a malicious YAML file with many omap entries that, when parsed via yaml.load(), forces the parser to perform redundant comparisons across all previously inserted items for each new insertion, exhausting CPU cycles.

Business impact

Applications relying on js-yaml to parse untrusted YAML input face denial-of-service risk. If user-supplied or external YAML documents are parsed without input validation or resource limits, an attacker can degrade application performance or render services unresponsive. This is particularly concerning for systems ingesting configuration files, API responses, or data pipelines where YAML is a common format. Organizations using js-yaml in production should prioritize understanding their exposure to untrusted YAML sources.

Affected systems

The nodeca js-yaml library versions 5.0.0 through 5.2.0 are affected. Any Node.js application or JavaScript environment (including Electron, Bundlers, and server-side runtimes) using an affected version of js-yaml in a context where yaml.load() processes untrusted or user-controlled YAML input is at risk.

Exploitability

Exploitability is straightforward: an attacker simply needs to provide a crafted YAML document with a large ordered-map structure to a system parsing it with a vulnerable version of js-yaml. No authentication, complex interaction, or special privileges are required. The attack vector is network-accessible, and the barrier to crafting a malicious YAML payload is low. However, real-world impact depends on the application's exposure to untrusted YAML input and any existing resource-limiting mechanisms.

Remediation

Update js-yaml to version 5.2.1 or later. Organizations should identify all dependencies on js-yaml across their codebase—both direct and transitive—and ensure updated versions are deployed. For development teams, this typically involves updating package.json and running dependency resolution tools (npm, yarn, pnpm) to pull in the patched version.

Patch guidance

Upgrade js-yaml to version 5.2.1 or above. Verify the upgrade by checking package.json, package-lock.json (or equivalent lock file), and confirming via npm list js-yaml that the installed version is 5.2.1 or later. For monorepos or complex dependency trees, use dependency scanning tools to confirm all transitive dependencies are updated. After patching, conduct a smoke test of YAML parsing functionality to ensure no regressions in your application.

Detection guidance

Review application logs and monitoring for signs of elevated CPU consumption correlating with YAML parsing operations. Check dependency manifests and lock files for js-yaml versions below 5.2.1. Use software composition analysis (SCA) tools to flag vulnerable versions in CI/CD pipelines. Monitor for unusual latency spikes when processing YAML inputs, which may indicate exploitation attempts. If you capture network traffic or log YAML payloads, look for omap tags with large numbers of entries.

Why prioritize this

This vulnerability warrants prompt but not emergency-level attention. The CVSS score of 5.3 (Medium) reflects limited availability impact with no confidentiality or integrity risk. However, denial-of-service vulnerabilities can disrupt service continuity, making patch deployment a high priority for systems accepting untrusted YAML. The fix is straightforward and low-risk, involving a minor version bump with no known breaking changes.

Risk score, explained

The CVSS 3.1 score of 5.3 reflects an attack vector that is network-accessible, requires no privileges or user interaction, and impacts only availability (not confidentiality or integrity). The Low (L) attack complexity indicates the exploit is straightforward to execute. The impact is rated as Low because the denial-of-service is resource exhaustion rather than complete system failure, and the vulnerability requires application-level exposure to untrusted YAML input.

Frequently asked questions