CVE-2025-64718

What it actually does

The flaw is a prototype pollution issue in js-yaml parsing of untrusted YAML. Versions before 4.1.1 and 3.14.2 can allow a YAML document containing a `__proto__` key to modify the prototype of the parsed result object. In JavaScript applications, polluted prototypes can change default object behavior and influence later authorization, configuration, validation, serialization, or business-logic decisions if the application merges or trusts parsed YAML data. The published CVSS indicates low-complexity, unauthenticated network exploitability where the primary direct impact is integrity rather than confidentiality or availability.

Why it matters to the business

Applications or tools that accept YAML from users, APIs, repositories, CI/CD inputs, configuration uploads, or automation workflows may allow attackers to tamper with application behavior. The most likely consequence is incorrect processing of data or settings, such as bypassing expected defaults or altering logic that relies on object properties. This is not currently listed in CISA KEV, has no known ransomware association, and has low EPSS at the time of assessment, but the library is commonly used across JavaScript ecosystems, so exposure can be widespread through direct and transitive dependencies.

How an attack unfolds

An attacker first identifies an application path that parses attacker-controlled YAML using a vulnerable js-yaml version. They submit a YAML document containing a prototype-polluting key such as `__proto__` with nested properties chosen to influence downstream code. js-yaml parses the document and returns an object whose prototype has been modified. If the application later merges, inspects, validates, or makes security or business decisions using ordinary JavaScript object property lookup, the attacker-controlled inherited property may be treated as if it were legitimate application data. The practical effect depends heavily on application logic: in some cases it may only corrupt parsed data; in more dangerous cases it can alter authorization flags, feature toggles, defaults, template behavior, or request-processing decisions. No public mature exploit or named threat-actor activity is indicated by the supplied data.

How to fix it

Upgrade js-yaml to a patched release: use js-yaml 4.1.1 or later for the 4.x line, or 3.14.2 or later for the 3.x line. Where the dependency is vendored or embedded, update to a build containing the upstream fix, including nodeca/js-yaml commit `cc482e775913e6625137572a3712d2826170e53a` or later. For github.com/cilium/hubble, upgrade to 1.17.2 or later. Regenerate lockfiles and container images so transitive copies are also replaced. If immediate upgrade is not possible for Node.js services, run with `node --disable-proto=delete` as a defense-in-depth mitigation. Deno users benefit from default prototype pollution protection, but should still update dependencies. Also avoid parsing untrusted YAML where possible, reject dangerous keys such as `__proto__`, `prototype`, and `constructor` at trust boundaries, and use schema validation that disallows unexpected properties.

How to confirm the fix worked

Confirm dependency versions with package manifests and lockfiles, such as `package.json`, `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, or SBOM output, and verify that no resolved js-yaml package is earlier than 4.1.1 or, for legacy 3.x use, earlier than 3.14.2. For Go or packaged products that include the vulnerable parser indirectly, verify the product version is at or above the fixed release, such as Hubble 1.17.2. Run software composition analysis across source repositories, built artifacts, and container images to catch transitive or bundled copies. As a functional validation, parse a controlled YAML test payload containing `__proto__` and confirm it does not modify object prototypes or inherited properties. For Node.js mitigations, verify runtime arguments include `--disable-proto=delete` where used. Rebuild and redeploy applications after updating lockfiles to ensure the fixed dependency is actually present at runtime.

Typical attack path

1. Locate an endpoint, CLI workflow, repository hook, import feature, CI/CD job, or configuration mechanism that accepts YAML from an untrusted source.
2. Confirm or infer that the target parses the YAML with js-yaml before 4.1.1 or 3.14.2, including through a transitive dependency.
3. Craft YAML containing a `__proto__` mapping with attacker-chosen nested properties.
4. Submit the malicious YAML through the exposed input channel.
5. Trigger application code that uses the parsed object or merges it with configuration/state objects.
6. Abuse polluted inherited properties to alter application decisions, corrupt data processing, or bypass expected validation depending on application behavior.

How to detect it

Retrospective detection should focus on places where YAML content enters the environment and on application behavior after parsing. Review HTTP access logs, API gateway logs, WAF logs, application request logs, upload/import records, repository webhook payloads, CI/CD job inputs, issue or ticket attachments, and configuration-management audit logs for YAML bodies or files containing `__proto__` keys. Search source-control activity and artifact stores for suspicious YAML files committed or uploaded by untrusted users. In application logs, look for parse events followed by unexpected authorization outcomes, configuration changes, validation bypasses, feature flag changes, or anomalous object/property errors. For Node.js workloads, inspect error telemetry for unusual inherited-property behavior, unexpected truthy flags, or messages involving prototype access. Because exploitation effects are application-specific and may not leave a distinctive process, file, or network artifact, payload-string searches are the most generally reusable detection method. If request bodies were not logged, use WAF/body-inspection telemetry, object-storage version history, CI job archives, and repository history to recover submitted YAML content.

• __proto__:
• "__proto__":
• '__proto__':
• __proto__]
• [__proto__]
• __proto__.polluted
• polluted: true
• polluted: yes
• isAdmin: true
• admin: true
• constructor:
• prototype:
• constructor.prototype
• node --disable-proto=delete

What your security team should do

• Inventory all applications, services, CLIs, developer tooling, CI/CD jobs, and import pipelines that parse YAML using js-yaml, especially where YAML can come from users, repositories, tickets, uploads, webhooks, or external automation.
• Prioritize upgrades for internet-facing services, multi-tenant systems, CI/CD infrastructure, developer portals, configuration importers, and any workflow that processes untrusted YAML.
• Upgrade js-yaml to 4.1.1 or later, or 3.14.2 or later where legacy 3.x compatibility is required; upgrade Hubble to 1.17.2 or later where applicable.
• Regenerate dependency lockfiles, rebuild containers, and redeploy rather than only changing manifest constraints.
• Add input validation or schema enforcement to reject prototype-pollution keys in YAML and other structured input formats.
• Use `node --disable-proto=delete` for Node.js workloads that cannot be immediately upgraded, while treating it as a temporary mitigation rather than a replacement for patching.
• Add regression tests that parse malicious YAML containing `__proto__` and assert that object prototypes are not changed.
• Review recent logs and uploaded/imported YAML artifacts for prototype-pollution payloads, particularly on systems that accepted untrusted YAML before patching.