GHSA-5p4m-2wfm-xmqj

# Quadratic CPU consumption in `!!omap` resolution (js-yaml 3.x and 4.x) ## Summary `resolveYamlOmap()` enforces key uniqueness for `!!omap` sequences with a linear scan (`objectKeys.indexOf(...)`) inside the per-element loop, making resolution **O(n²)** in the number of entries. A modestly sized YAML document therefore consumes disproportionate CPU inside `yaml.load()`, giving a denial of service against any consumer that parses untrusted YAML. `!!omap` is registered in the **default schema** (`lib/schema/default.js` → `require('../type/omap')`), so a plain `yaml.load(untrustedInput)` with no options is affected — no custom schema or non-default configuration is required. **This is the same weakness as CVE-2026-59870 / GHSA-724g-mxrg-4qvm**, which was fixed in the 5.x line in 5.2.1. That fix was never backported: both currently maintained legacy lines still carry the original implementation. ## Affected versions | Line | Latest tested | Status | |---|---|---| | 3.x | **3.15.0** | Affected — `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:29` | | 4.x | **4.3.0** | Affected — `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:30` | | 5.x | 5.2.2 | **Not affected** — fixed in 5.2.1 (uses a `Set`) | Both figures are the newest release of each line at the time of writing, so this is not a "you are on an old version" issue. ## Details `lib/type/omap.js` (js-yaml 4.3.0): ```js if (objectKeys.indexOf(pairKey) === -1) objectKeys.push(pairKey) else return false ``` `objectKeys` grows by one element per entry, and `Array.prototype.indexOf` is a linear scan, so resolving an `n`-entry `!!omap` performs roughly `1 + 2 + … + n` comparisons — quadratic in `n`. The work happens synchronously inside `yaml.load()`, blocking the event loop for its whole duration. The 5.x line already solves exactly this by tracking seen keys in a `Set` (`src/tag/sequence/omap.ts`): ```ts if (carrier.seen.has(key)) return 'duplicate key in ordered map' carrier.seen.add(key) ``` ## Proo