GHSA-2pr6-76vf-7546

What it actually does

Affected versions of the js-yaml npm package before 3.13.0 can be forced into excessive resource consumption while parsing specially crafted YAML input. When an application accepts untrusted YAML and processes it with a vulnerable js-yaml version, an attacker can trigger high CPU usage, memory exhaustion, process crashes, or event-loop blockage, resulting in denial of service. The issue does not directly provide code execution or data disclosure, but it can make services unavailable if YAML parsing is exposed through APIs, file uploads, CI/CD configuration processing, import workflows, or other user-controlled input paths.

Why it matters to the business

Successful exploitation can interrupt services that depend on YAML parsing, causing application downtime, failed automation jobs, degraded API availability, or resource exhaustion in shared runtime environments. Because js-yaml is a common dependency in JavaScript tooling and applications, exposure may exist indirectly through downstream packages even when the application does not explicitly use it. This vulnerability is older and is not listed in CISA KEV, and no exploit maturity is reported in the provided data, but affected deployments should still be remediated because denial-of-service payloads are often simple to reproduce once an input path is found.

How an attack unfolds

An attacker first identifies an application feature that accepts or processes YAML content, such as configuration import, document upload, API payload parsing, repository scanning, CI pipeline configuration, or administrative tooling exposed through a web interface. The attacker then submits a malicious YAML document designed to trigger inefficient parsing behavior in vulnerable js-yaml versions. When the application passes that content to js-yaml, the Node.js process may consume excessive CPU or memory, block the event loop, throw fatal allocation or recursion errors, or crash. Repeated submissions can keep the service unavailable, especially when parsing occurs synchronously in the main application process or when worker restarts are automatic.

How to fix it

Upgrade js-yaml to version 3.13.0 or later. For npm-based projects, update direct dependencies in package.json and regenerate lockfiles, then rebuild and redeploy artifacts that bundle js-yaml. Also review transitive dependency paths using npm audit, npm ls js-yaml, yarn why js-yaml, or equivalent tooling, because vulnerable versions may be pulled in by other packages. If immediate upgrade is not possible, reduce risk by rejecting untrusted YAML where feasible, enforcing strict request and file-size limits, parsing YAML in isolated worker processes with memory and CPU limits, applying timeouts, limiting concurrent parse operations, and rate-limiting endpoints that accept YAML input.

How to confirm the fix worked

Confirm that dependency resolution no longer installs vulnerable js-yaml versions. Validate with package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls js-yaml, and software composition analysis output. The installed version should be 3.13.0 or later for the affected package line. Exercise application features that parse YAML using representative valid inputs to confirm no regression. Where safe, test with intentionally oversized or alias-heavy YAML in a controlled non-production environment to verify that limits, timeouts, and error handling prevent service instability. Confirm deployed containers, serverless packages, build artifacts, and CI images have been rebuilt rather than only updating source manifests.

Typical attack path

1. Find an endpoint, upload feature, automation workflow, or backend job that accepts YAML content from untrusted or semi-trusted users.
2. Confirm the target application or one of its dependencies uses js-yaml before version 3.13.0.
3. Craft a YAML payload that abuses parser behavior to consume excessive CPU, memory, or recursion depth.
4. Submit the payload through the exposed YAML-processing path.
5. Cause the Node.js process, worker, or job runner to hang, restart, crash, or become unresponsive.
6. Repeat the request or upload to sustain denial of service if rate limits and resource controls are absent.

How to detect it

To assess whether this was already exploited, review application, reverse proxy, API gateway, container, process manager, and host logs around periods of service degradation or restarts. Look for requests that upload or submit YAML content shortly before Node.js crashes, high CPU, memory exhaustion, worker restarts, HTTP 502/503/504 spikes, or application timeouts. Examine logs from CI/CD systems, repository scanners, configuration importers, and background job workers that parse YAML. Relevant artifacts include repeated parse errors, fatal Node.js heap errors, stack overflows, abrupt process exits, orchestrator restarts, OOMKilled events, and unusually large or alias-heavy YAML files. If request bodies are logged or recoverable from forensic captures, look for YAML documents containing dense anchors, aliases, merge keys, or repeated nested references submitted to parsing endpoints. There are no known threat actors or KEV-listed exploitation details in the provided data, so detection should focus on behavioral evidence of denial-of-service attempts rather than actor-specific infrastructure.

• js-yaml@3.12.
• "js-yaml": "3.12.
• "node_modules/js-yaml"
• RangeError: Maximum call stack size exceeded
• JavaScript heap out of memory
• FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed
• ENOMEM
• OOMKilled
• Process exited with code 134
• Process exited with code 137
• YAMLException
• <<: *
• &a
• *a

What your security team should do

• Inventory all JavaScript and Node.js applications, CI/CD tooling, and internal automation that include js-yaml directly or transitively.
• Prioritize remediation for internet-facing services, multi-tenant systems, upload/import workflows, and CI/CD components that process YAML from users or repositories.
• Upgrade js-yaml to 3.13.0 or later and ensure lockfiles and deployed artifacts reflect the fixed version.
• Add size limits, parsing timeouts, worker isolation, memory limits, and rate limits around YAML-processing functionality.
• Search logs and telemetry for prior crashes, memory exhaustion, repeated YAML parse failures, or request bursts against YAML upload/import endpoints.
• Add dependency scanning gates to prevent reintroduction of js-yaml versions earlier than 3.13.0.
• Document whether any exposed YAML-processing path accepts untrusted input; if none exists, record the reduced exploitability but still remediate the vulnerable dependency.