CVE-2026-33532

What it actually does

CVE-2026-33532 is a denial-of-service flaw in the JavaScript `yaml` package. During YAML composition and node resolution, affected versions use recursive function calls without enforcing a maximum nesting depth. A deeply nested YAML flow sequence can exhaust the Node.js call stack and throw `RangeError: Maximum call stack size exceeded`. Because this exception is not a `YAMLParseError`, applications that only handle YAML-specific parsing errors may fail the current request, return errors, crash a worker, or terminate the Node.js process depending on process-level exception handling. The vulnerable APIs are `YAML.parse()`, `YAML.parseDocument()`, and `YAML.parseAllDocuments()`. The lower-level CST `Parser` phase is not affected.

Why it matters to the business

Applications that accept YAML input from users, API clients, repositories, CI/CD pipelines, configuration uploads, or integration partners may be vulnerable to low-effort service disruption. The payload can be small, roughly a few kilobytes, so exploitation may be practical even where request-size limits exist. The main business risk is reduced availability: failed requests, degraded service reliability, crashed Node.js workers, interrupted automation, or repeated restarts in services that parse untrusted YAML. The CVSS score is moderate and EPSS is low, and it is not currently listed in CISA KEV or associated with ransomware, but internet-facing or automation-critical services should still prioritize remediation because the attack is simple and does not require a large payload.

How an attack unfolds

An attacker first identifies an application path that parses attacker-controlled YAML using the `yaml` JavaScript package, such as a configuration upload, API endpoint, CI workflow parser, infrastructure-as-code intake, document import feature, or webhook processor. The attacker then submits a YAML document containing extremely deep nesting, commonly using flow sequences because each nesting level can be represented compactly with `[` and `]`. When the application calls `YAML.parse()`, `YAML.parseDocument()`, or `YAML.parseAllDocuments()`, the parser reaches the compose/resolve phase and recursively processes the nested structure. On affected versions, there is no sufficient recursion-depth bound, so the Node.js call stack is exhausted. The runtime throws `RangeError: Maximum call stack size exceeded`. If the host application does not catch this generic exception and recover safely, the request fails and in some deployments the Node.js process or worker exits. Repeated submissions can cause recurring errors, worker churn, or service unavailability.

How to fix it

Upgrade the `yaml` package to a patched version. For the 1.x branch, upgrade to `yaml` 1.10.3 or later. For the 2.x branch, upgrade to `yaml` 2.8.3 or later. Regenerate and redeploy lockfiles so transitive dependencies are also updated where applicable. If immediate upgrade is not possible, apply compensating controls: reject or cap excessively nested YAML before parsing, enforce small request/body limits appropriate to the feature, parse untrusted YAML in an isolated worker with restart and timeout controls, catch generic exceptions around YAML parsing rather than only `YAMLParseError`, and return controlled validation errors instead of allowing process-level crashes. Avoid parsing untrusted YAML in long-lived privileged processes when isolation is available.

How to confirm the fix worked

Confirm dependency versions using package-manager and SBOM data. For npm-based projects, check `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, and deployed artifact manifests for `yaml` versions earlier than 1.10.3 on the 1.x branch or earlier than 2.8.3 on the 2.x branch. Run `npm ls yaml`, `yarn why yaml`, or `pnpm why yaml` in each application build context. Validate that deployed containers or serverless bundles contain the upgraded package, not only the source repository. As a functional test, submit a safely controlled deeply nested YAML sample in a non-production test environment and verify that the application returns a controlled validation error, does not log an uncaught `RangeError`, and does not restart or terminate the Node.js process. Review process manager, container, and application logs to confirm no crash loop or unhandled exception occurs after remediation.

Typical attack path

1. Locate an application feature or service that accepts YAML from an external or lower-trust source.
2. Confirm that the backend parses the input with the JavaScript `yaml` package on an affected 1.x or 2.x version.
3. Craft a small YAML payload with deeply nested flow sequences, using many layers of square brackets.
4. Submit the payload to the vulnerable endpoint, job processor, repository hook, or import function.
5. Trigger recursive composition/resolution in `YAML.parse()`, `YAML.parseDocument()`, or `YAML.parseAllDocuments()`.
6. Cause Node.js to throw `RangeError: Maximum call stack size exceeded`.
7. Rely on insufficient exception handling to fail the request, crash a worker, terminate the process, or repeatedly degrade service availability.

How to detect it

Look for evidence of attempted or successful denial-of-service through YAML parsing. Useful sources include application logs, Node.js stderr/stdout logs, process manager logs, container runtime events, Kubernetes pod restart events, API gateway logs, web server access logs, CI/CD job logs, and error tracking systems. Search for `RangeError: Maximum call stack size exceeded` occurring during YAML parsing, especially where stack traces reference the `yaml` package or parsing functions such as `parse`, `parseDocument`, or `parseAllDocuments`. Correlate these errors with inbound requests, uploads, webhooks, repository events, or job submissions containing YAML content. Indicators of success include repeated HTTP 500 responses, abrupt Node.js process exits, worker restarts, container restarts, `CrashLoopBackOff`, failed CI jobs, or process-manager restart messages immediately after YAML parsing errors. Inspect suspicious request bodies or uploaded files for extreme nesting using long runs of `[` characters followed by matching `]` characters, particularly payloads only a few kilobytes in size. Since this is an availability issue, absence of persistent malware artifacts is expected; detection depends primarily on logs, crash evidence, and suspicious malformed YAML inputs.

• RangeError: Maximum call stack size exceeded
• YAMLParseError
• YAML.parse
• YAML.parseDocument
• YAML.parseAllDocuments
• node_modules/yaml/
• CrashLoopBackOff
• UnhandledPromiseRejection
• uncaughtException
• Maximum call stack size exceeded
• [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[
• at Object.parse
• at parseDocument
• at parseAllDocuments

What your security team should do

• Inventory all applications, build tools, CI/CD services, import pipelines, and APIs that parse YAML using the JavaScript `yaml` package.
• Prioritize internet-facing services, multi-tenant services, webhook handlers, CI/CD automation, and any system that parses YAML from repositories or users.
• Upgrade `yaml` to 1.10.3 or later for 1.x deployments and 2.8.3 or later for 2.x deployments; rebuild and redeploy artifacts after lockfile updates.
• Add generic exception handling around YAML parsing so unexpected parser exceptions cannot terminate the Node.js process.
• Implement input-depth, request-size, timeout, and worker-isolation controls for untrusted YAML parsing.
• Add monitoring for `RangeError: Maximum call stack size exceeded` near YAML parsing paths, especially spikes correlated with a single source IP, account, repository, or integration.
• Review recent logs for unexplained Node.js worker exits, container restarts, HTTP 500 spikes, and parser errors since the vulnerability publication date.
• Because the issue is not in CISA KEV and has low EPSS, schedule broadly based on exposure, but treat externally reachable YAML parsing paths as higher priority due to the very small payload size required.