CVE-2026-53550

What it actually does

CVE-2026-53550 is an algorithmic complexity denial-of-service vulnerability in nodeca js-yaml before version 4.2.0. A specially crafted YAML document can abuse merge-key processing using the YAML merge key (`<<`) and repeated aliases in a merge sequence, causing quadratic CPU consumption during parsing. In Node.js applications, this can block the event loop or worker thread for seconds with a relatively small YAML payload, degrading or preventing normal request handling. The vulnerable logic is in `lib/loader.js`. The impact is availability only; the issue does not provide code execution, data disclosure, or data modification by itself.

Why it matters to the business

Applications, APIs, CI/CD tooling, configuration import features, developer portals, or backend services that parse untrusted YAML with vulnerable js-yaml versions can be made slow or temporarily unavailable with small malicious inputs. Because Node.js services often rely on a single event loop per worker, one expensive parse operation can delay many unrelated requests. The CVSS score is medium and EPSS is currently low, and it is not listed in CISA KEV or associated with ransomware campaigns, but exposure is still operationally relevant for internet-facing upload, import, validation, or automation workflows that accept YAML from unauthenticated users.

How an attack unfolds

An attacker identifies an application path that accepts YAML content and parses it server-side using js-yaml before 4.2.0. The attacker sends a crafted YAML document containing anchors and a merge key (`<<`) whose merge sequence repeats the same alias many times. During parsing, vulnerable merge handling repeatedly processes the aliased mapping in a way that grows quadratically with the input size. Even though the payload may only be tens of kilobytes, CPU usage spikes and the Node.js event loop or worker is blocked until parsing completes. By sending one or more such requests, the attacker can degrade response times, exhaust available worker capacity, trigger health-check failures, or cause denial of service for other users.

How to fix it

Upgrade js-yaml to version 4.2.0 or later everywhere it is used, including direct and transitive dependencies. If package manifests do not already resolve to the fixed release, update lockfiles and rebuild/redeploy affected applications. Use dependency override mechanisms where necessary to force vulnerable transitive copies to 4.2.0 or later. As compensating controls, do not parse untrusted YAML on latency-sensitive event-loop threads; enforce strict request body size limits; apply parsing timeouts or worker isolation; rate-limit YAML upload/import endpoints; reject YAML merge keys (`<<`) where they are not required; and place expensive parsing in separate worker processes with resource limits.

How to confirm the fix worked

Confirm that dependency inventory, lockfiles, SBOMs, and deployed artifacts resolve `js-yaml` to 4.2.0 or later. Check for vulnerable copies with commands such as `npm ls js-yaml`, `yarn why js-yaml`, `pnpm why js-yaml`, and software composition analysis tools. Validate that production containers or bundles do not include older `node_modules/js-yaml` copies. Where safe, run a controlled regression test using a benign merge-key stress document against a non-production instance and verify that parsing completes quickly or is rejected by input controls. Also verify that request size limits, rate limits, and parser isolation controls behave as expected.

Typical attack path

1. Find an endpoint, job, webhook, file upload, API, or automation feature that accepts YAML input.
2. Confirm the service parses YAML server-side with a vulnerable js-yaml version before 4.2.0.
3. Prepare YAML containing an anchor, a merge key (`<<`), and a merge sequence that repeats the same alias many times.
4. Submit the crafted YAML payload to the target feature.
5. Cause excessive CPU consumption during YAML parsing, blocking the Node.js event loop or worker.
6. Repeat or parallelize requests to sustain degraded performance or denial of service.

How to detect it

To determine whether exploitation has already occurred, review application access logs, API gateway logs, WAF logs, upload/import audit logs, and Node.js application telemetry for requests containing YAML merge keys and repeated aliases followed by abnormal latency, timeouts, CPU saturation, event-loop lag, worker restarts, or health-check failures. Focus on endpoints that accept `.yaml` or `.yml` uploads, configuration imports, CI/CD definitions, repository webhooks, automation templates, or YAML request bodies. In application logs, look for parse operations with unusually long duration, request bodies or filenames associated with YAML ingestion, repeated HTTP 408/429/499/500/502/503/504 responses, and spikes in CPU without corresponding traffic growth. In host/container telemetry, correlate high CPU usage by Node.js processes with inbound YAML parsing requests. There are no known public exploit-specific filenames, hashes, actor infrastructure, or ransomware indicators from the provided intelligence; detection should therefore rely on payload structure and behavioral evidence.

• <<:
• <<: [
• &
• *
• js-yaml
• lib/loader.js
• YAMLException
• node
• event loop lag
• JavaScript heap out of memory
• HTTP 408
• HTTP 499
• HTTP 500
• HTTP 502
• HTTP 503
• HTTP 504
• .yaml
• .yml

What your security team should do

• Prioritize upgrading all direct and transitive js-yaml dependencies to 4.2.0 or later in applications that parse YAML from users, integrations, webhooks, repositories, CI jobs, or uploaded files.
• Search dependency inventories, SBOMs, container images, and lockfiles for js-yaml versions before 4.2.0.
• Identify externally reachable or unauthenticated YAML parsing paths and apply rate limits, request size limits, and authentication where appropriate.
• Add negative tests for YAML merge-key alias repetition to prevent regression in services that accept YAML.
• Monitor application performance telemetry for CPU spikes, event-loop lag, request timeouts, and increased latency associated with YAML parsing routes.
• If immediate upgrade is not possible, block or reject YAML merge keys (`<<`) for untrusted inputs and isolate parsing in bounded worker processes.
• Because there is no KEV listing and EPSS is low, prioritize based on exposure: internet-facing and unauthenticated YAML ingestion should be handled before internal-only tooling.