CVE-2026-59869

What it actually does

This vulnerability is an algorithmic denial-of-service flaw in the js-yaml parser. A specially crafted YAML document can force js-yaml to consume quadratic CPU time during parsing by chaining YAML mappings that repeatedly use merge keys to merge the previous mapping. Because the input grows linearly while parser work grows much faster, a relatively small document can tie up the event loop or worker process long enough to cause request timeouts, service degradation, or process exhaustion. The flaw affects js-yaml versions 3.0.0 through versions before 3.15.0 and 4.0.0 through versions before 4.3.0.

Why it matters to the business

Applications, APIs, build systems, CI/CD workflows, developer tools, and backend services that parse untrusted YAML using vulnerable js-yaml versions can be made slow or unavailable by a remote unauthenticated attacker if YAML input is exposed over a network path. The primary business risk is service disruption: degraded availability, failed jobs, customer-facing outages, increased infrastructure cost from CPU saturation, and cascading failures in dependent services. The CVSS availability impact is high, and exploit code is reported as available, but the current EPSS score is low and the issue is not listed in CISA KEV, so prioritization should focus first on internet-facing or automation-critical systems that accept YAML from users, repositories, webhooks, uploads, or API calls.

How an attack unfolds

An attacker identifies an application or service path that accepts YAML input and parses it with a vulnerable js-yaml release. The attacker submits a syntactically valid YAML document containing a chain of mappings where each mapping uses the YAML merge key to include the previous mapping. As js-yaml expands and resolves these chained merges, CPU work grows quadratically relative to the input size. If the parser runs in a Node.js request handler, worker, job processor, webhook handler, configuration importer, or CI/CD task, the parsing operation can monopolize CPU and block useful work. Repeated submissions can keep processes saturated, produce request timeouts, starve the Node.js event loop, exhaust worker pools, or trigger autoscaling and crash-restart behavior, resulting in a denial of service without needing authentication when the parsing endpoint is publicly reachable.

How to fix it

Upgrade js-yaml to a fixed version: use js-yaml 3.15.0 or later for the 3.x branch, or js-yaml 4.3.0 or later for the 4.x branch. Prefer moving to the latest compatible maintained release and ensure transitive dependencies are also updated through package manager lockfile refreshes and dependency overrides where necessary. If immediate upgrade is not possible, reduce exposure by rejecting untrusted YAML, enforcing strict request body size limits, applying parsing timeouts or worker isolation, rate-limiting YAML-processing endpoints, and disabling or pre-filtering YAML merge-key-heavy documents where compatible with business needs. For services that parse YAML in request paths, consider moving parsing to bounded worker processes with CPU and wall-clock limits so one input cannot block the main application event loop.

How to confirm the fix worked

Confirm the installed js-yaml versions across package manifests and lockfiles are not in the vulnerable ranges: 3.0.0 to before 3.15.0, or 4.0.0 to before 4.3.0. Use package manager inspection commands such as npm ls js-yaml, yarn why js-yaml, or pnpm why js-yaml, and verify container images and deployed artifacts rather than only source repositories. Review package-lock.json, yarn.lock, pnpm-lock.yaml, and SBOM output for vulnerable transitive copies. After upgrading, run regression tests against normal YAML inputs and a controlled proof-of-concept merge-chain YAML sample to verify parsing completes within expected CPU and wall-clock bounds. For internet-facing features, validate that body-size limits, rate limits, and timeout controls are enforced before YAML parsing occurs.

Typical attack path

1. Discover an application feature, API, webhook, upload, repository import, configuration parser, or automation job that accepts YAML content.
2. Confirm or infer that the target uses a vulnerable js-yaml version before 3.15.0 in the 3.x line or before 4.3.0 in the 4.x line.
3. Craft a YAML document with chained mappings, anchors, aliases, and repeated merge keys where each mapping merges the previous mapping.
4. Submit the crafted YAML through the exposed input path.
5. Trigger excessive CPU consumption during parsing, causing slow responses, event-loop blocking, worker saturation, or process timeouts.
6. Repeat or parallelize submissions to maintain service degradation or outage.

How to detect it

To determine whether this was already exploited, review application, API gateway, reverse proxy, WAF, job processor, and CI/CD logs for requests or jobs that submitted YAML content immediately before CPU spikes, request timeouts, process restarts, or elevated 5xx/504 responses. Focus on endpoints and workflows that import configuration, parse uploaded YAML, process repository files, handle webhooks, or run automation using YAML manifests. Look for request bodies, uploaded files, or repository commits containing unusually long chains of YAML anchors, aliases, and merge keys, especially repeated occurrences of the merge key token "<<:". In Node.js services, correlate event-loop lag, high CPU, garbage collection pressure, worker queue backlog, and process supervisor restarts with YAML parsing operations. For forensics, preserve suspicious YAML payloads, access logs, application exception logs, job execution metadata, container stdout/stderr, process metrics, and package lockfiles showing vulnerable js-yaml versions. Successful exploitation is unlikely to leave a unique file-system artifact unless the application stores uploaded YAML; detection is therefore primarily behavioral and payload-pattern based.

• js-yaml@3.0.0
• js-yaml@3.1.0
• js-yaml@3.2.0
• js-yaml@3.3.0
• js-yaml@3.4.0
• js-yaml@3.5.0
• js-yaml@3.6.0
• js-yaml@3.7.0
• js-yaml@3.8.0
• js-yaml@3.9.0
• js-yaml@3.10.0
• js-yaml@3.11.0
• js-yaml@3.12.0
• js-yaml@3.13.0
• js-yaml@3.14.0
• js-yaml@4.0.0
• js-yaml@4.1.0
• js-yaml@4.2.0
• node_modules/js-yaml/package.json
• "js-yaml": "3.
• "js-yaml": "4.0
• "js-yaml": "4.1
• "js-yaml": "4.2
• <<: *
• <<: [
• &a0
• *a0

What your security team should do

• Inventory all applications, services, CLI tools, CI/CD workflows, and containers that include js-yaml, including transitive dependencies in lockfiles and SBOMs.
• Prioritize remediation for internet-facing services, webhook receivers, repository importers, file upload handlers, developer portals, CI/CD systems, and any workflow that parses YAML from untrusted users or third-party repositories.
• Upgrade to js-yaml 3.15.0 or later on the 3.x line, or 4.3.0 or later on the 4.x line; prefer the latest compatible release.
• Add dependency override or resolution rules where vulnerable js-yaml versions are pulled transitively by other packages.
• Apply compensating controls while upgrades are pending: request size limits, rate limits, parser timeouts, worker isolation, and CPU limits for YAML-processing tasks.
• Search application and edge logs for unusual spikes in YAML submissions, repeated requests to YAML-import endpoints, high request duration, HTTP 408/429/500/502/503/504 responses, and CPU saturation correlated with YAML parsing.
• Add tests for resource-exhaustion inputs to prevent reintroduction of vulnerable parser versions or unsafe parsing patterns.
• Because exploit code is available, treat exposed YAML parsing paths as higher priority even though the issue is not currently in CISA KEV and has a low EPSS score.