GHSA-8j8c-7jfh-h6hx

What it actually does

The flaw is a code injection vulnerability in js-yaml, a JavaScript YAML parser. Vulnerable versions can execute attacker-controlled JavaScript when parsing specially crafted YAML content through unsafe loading behavior. If an application accepts YAML from an untrusted source and processes it with an affected js-yaml version or unsafe parsing APIs, the attacker may be able to run arbitrary code in the context of the Node.js process.

Why it matters to the business

Applications that parse user-supplied YAML with vulnerable js-yaml versions may allow attackers to take control of the application process, access secrets, modify data, or pivot to connected services. Because js-yaml is a common npm dependency and the issue has been public since 2019, exposed instances should be treated as hygiene-critical even though it is not currently listed in CISA KEV and no active ransomware linkage is indicated.

How an attack unfolds

An attacker first identifies an application feature, API, import workflow, CI/CD tool, configuration endpoint, or administrative function that accepts YAML input. They then submit a malicious YAML document designed to trigger unsafe object construction or code execution behavior in the vulnerable js-yaml parser. When the application parses the payload using the affected library path, embedded JavaScript is evaluated by the Node.js runtime. Successful exploitation gives the attacker code execution with the privileges of the affected process, which can then be used to read environment variables, steal credentials, write files, spawn child processes, or interact with internal services reachable from the application.

How to fix it

Upgrade js-yaml to version 3.13.1 or later wherever it is used. The fixed package version is: js-yaml (npm) fixed in 3.13.1. Rebuild and redeploy applications after dependency updates, including transitive dependency resolution through lockfiles. Avoid unsafe YAML parsing for untrusted input; use safe parsing APIs and restrict schemas to only the types required by the application. If immediate upgrade is not possible, disable YAML upload/import features exposed to untrusted users, validate and constrain accepted YAML content, and run affected parsing workloads with least privilege and strong isolation.

How to confirm the fix worked

Confirm that package manifests and lockfiles resolve js-yaml to 3.13.1 or later, including transitive dependencies. Use software composition analysis, npm audit, yarn audit, pnpm audit, or equivalent dependency scanners to verify that no vulnerable js-yaml versions remain in deployed artifacts. Test application workflows that parse YAML to ensure they still function using safe schemas and do not evaluate arbitrary JavaScript. Where feasible, submit a benign regression test payload in a non-production environment to confirm that unsafe JavaScript execution is rejected rather than evaluated.

Typical attack path

1. Find an exposed feature or service that accepts YAML input, such as configuration upload, import/export, automation, or build tooling.
2. Determine or infer that the application uses a vulnerable version of js-yaml and an unsafe parsing path.
3. Craft YAML content containing a JavaScript execution payload that abuses vulnerable js-yaml behavior.
4. Submit the malicious YAML through the exposed interface or supply-chain/configuration path.
5. Wait for the application or tool to parse the YAML payload.
6. Execute commands or JavaScript in the context of the Node.js process.
7. Use the resulting access to read secrets, modify application state, deploy persistence, or move laterally.

How to detect it

Review application, API gateway, web server, and upload/import workflow logs for YAML submissions immediately followed by errors, process crashes, unusual command execution, outbound network connections, or access to sensitive files. Examine Node.js runtime telemetry and EDR records for child processes spawned by services that normally only parse configuration or data, especially shells, curl/wget, scripting interpreters, or file modification commands. Inspect CI/CD and automation logs if YAML is parsed during builds or deployments, as exploitation may occur through repository files or configuration imports rather than direct web requests. Check historical dependency and deployment records to identify periods when vulnerable js-yaml versions were present. Because exploit payloads vary and no single universal IOC is available, focus on behavioral evidence: unexpected child_process activity, anomalous environment-variable access, suspicious YAML tags or JavaScript function bodies in uploaded content, and network egress from parsing services.

• js-yaml@3.13.0
• js-yaml@3.12.
• js-yaml@3.11.
• js-yaml@3.10.
• js-yaml@3.9.
• !!js/function
• !!js/regexp
• !!js/undefined
• Function(
• child_process
• require('child_process')
• require("child_process")
• process.env
• /bin/sh
• /bin/bash
• cmd.exe
• powershell.exe
• curl
• wget
• nc -e
• bash -i

What your security team should do

• Inventory all applications, build systems, CLI tools, and automation workflows that include js-yaml.
• Prioritize remediation for internet-facing services, CI/CD systems, administrative consoles, and any workflow that parses YAML supplied by users, partners, repositories, or uploaded files.
• Upgrade js-yaml to 3.13.1 or later and refresh lockfiles and container images to ensure the fixed dependency is actually deployed.
• Search for use of unsafe parsing APIs and replace them with safe parsing patterns and restrictive schemas.
• Add dependency scanning gates to CI/CD so vulnerable js-yaml versions cannot be reintroduced.
• Review logs and telemetry for suspicious YAML uploads, unexpected Node.js child processes, and outbound connections from services that parse YAML.
• Run affected services with least privilege, read-only filesystems where possible, and restricted network egress to limit impact from any parser-level compromise.