The vulnerability in js‑yaml arises from how the !!omap tag is parsed under YAML11_SCHEMA. In versions prior to 3.15.1, 4.3.1, and 5.2.1, every insertion of an ordered‑map item triggers a linear duplicate‑key scan, which results in an overall O(n^2) CPU cost when yaml.load() processes a crafted document. In v5 the !!omap tag is not enabled by default, and the chances of activating it are very low, but if it is enabled the same quadratic complexity can be triggered. An attacker can supply a YAML file with many ordered‑map entries to exhaust CPU resources, leading to a denial‑of‑service condition. The flaw is characterized by CWE‑407 and CWE‑770, and no remote code execution or information disclosure paths are exposed.

The flaw affects the nodeca js‑yaml package across multiple major releases: all versions prior to 3.15.1, all versions prior to 4.3.1, and all versions prior to 5.2.1. Any application or service that includes one of these vulnerable versions—directly or through a dependency chain—operating in any JavaScript environment (Node.js, browser, etc.) is vulnerable when it processes YAML input with YAML11_SCHEMA support for the !!omap tag. In v5 the !!omap tag is not enabled by default, but can be activated and would trigger the same quadratic logic; thus it is considered lower risk but still exploitable if enabled.

The CVSS score of 7.5 reflects a high severity, and the EPSS score, currently less than 1%, indicates a very low but non‑zero exploitation probability. The vulnerability is not listed in CISA KEV. Exploitation requires the attacker to supply a crafted YAML document to any code path that invokes yaml.load(); therefore the attack vector is likely local or through an application that accepts user‑supplied YAML. Although no publicly disclosed exploit code exists, the DoS impact could degrade service availability in production deployments if a high‑volume ordered‑map payload is delivered.