Investigate js-yaml DoS alert — no viable dependency change (reverted to base)

[Copilot]

Dependabot flagged GHSA-h67p-54hq-rp68 / CVE-2026-53550: js-yaml merge-key alias handling can cause quadratic CPU usage and parser DoS. After investigation, the previously proposed remediation was reverted because it was unnecessary for the direct dependency and broke runtime behavior for the transitive consumers. This PR now contains no net change relative to base.

• Investigation outcome

  • The direct js-yaml dependency already resolves to the patched 4.2.0 at base (it satisfies ^4.1.0), so no package.json or lockfile change was needed for it.
  • The remaining vulnerable copies are transitive js-yaml@3.14.2, required as ^3.13.1 by @azure/openapi-markdown (runtime), front-matter, and @istanbuljs/load-nyc-config.
  • Forcing those transitive copies to 4.2.0 via an npm override breaks them because they call js-yaml.safeLoad, which was removed in js-yaml 4.x. This caused 7 of 8 readme-parsing cases in exampleGeneratorTests to fail (readme YAML parsed to empty []). The earlier snapshot edit had been masking that regression.
  • A lockfile-only update cannot fix the transitive copies either, since there is no compatible patched 3.x release.

• Reverted changes

  • Reverted the direct dependency pin (js-yaml back to ^4.1.0).
  • Removed the js-yaml npm override.
  • Reverted package-lock.json to base.
  • Reverted test/__snapshots__/exampleGeneratorTests.ts.snap to base.

• Validation

  • Full exampleGeneratorTests suite passes (8/8) on the reverted state.

• Reachability assessment

  • The codebase parses YAML in runtime paths (e.g., lib/util/utils.ts via YAML.load, lib/swagger/jsonLoader.ts via the js-yaml load API). Those direct usages run on the patched 4.2.0. The transitive 3.14.2 copies cannot be remediated without breaking runtime YAML parsing or an upstream bump of @azure/openapi-markdown / front-matter, so handling of the alert (e.g. dismiss/suppress vs. wait for upstream) is deferred to the maintainer.

Original prompt

---

This section details the Dependabot vulnerability alert you should resolve

<alert_title>JS-YAML: Quadratic-complexity DoS in merge key handling via repeated aliases</alert_title>
<alert_description>### Summary
A crafted YAML document can trigger algorithmic CPU exhaustion in js-yaml merge-key processing (<<) by repeating the same alias many times in a merge sequence.
This causes quadratic parse-time behavior relative to input size and can block a Node.js worker/event loop for seconds with a relatively small payload (tens of KB), resulting in denial of service.

Details

The issue is in merge handling inside lib/loader.js:

• storeMappingPair(...) iterates every element of a merge sequence when key tag is tag:yaml.org,2002:merge.
• For each element, it calls mergeMappings(...).
• mergeMappings(...) computes Object.keys(source) and performs _hasOwnProperty.call(destination, key) checks for each key.

When input is of the form:

a: &a {k0:0, k1:0, ..., kK:0}
b: {<<: [*a, *a, *a, ... repeated M times ...]}
all *a entries refer to the same anchored object. After the first merge, subsequent merges are semantically no-ops, but the parser still reprocesses all keys each time.
Resulting work is O(K * M), while input size is O(K + M), giving quadratic scaling as payload grows.
Relevant code path:
lib/loader.js in storeMappingPair(...) merge branch (keyTag === 'tag:yaml.org,2002:merge')
lib/loader.js mergeMappings(...)

Root cause

File: lib/loader.js
Function: storeMappingPair(state, _result, overridableKeys, keyTag, keyNode,
valueNode, startLine, startLineStart, startPos)
Lines: ~359-366

if (keyTag === 'tag:yaml.org,2002:merge') {
  if (Array.isArray(valueNode)) {
    for (index = 0, quantity = valueNode.length; index < quantity; index += 1) {
      mergeMappings(state, _result, valueNode[index], overridableKeys);
    }
  } else {
    mergeMappings(state, _result, valueNode, overridableKeys);
  }
}

When the merge value is a sequence (YAML 1.1 <<: [ *a, *a, ... ]), each element
is handed to mergeMappings() without deduplication. mergeMappings() then does

sourceKeys = Object.keys(source);
for (index = 0; index < sourceKeys.length; index += 1) {
  key = sourceKeys[index];
  if (!_hasOwnProperty.call(destination, key)) {
    setProperty(destination, key, source[key]);
    overridableKeys[key] = true;
  }
}

Every alias reference in the sequence resolves (by design) to the SAME object
via state.anchorMap. After the first merge, every subsequent merge of that same
reference is a pure no-op semantically, but still performs:

• one Object.keys(source) call (O(K))
• K _hasOwnProperty.call checks on the destination

Total: M * K hasOwnProperty checks + M Object.keys allocations, while the final
object and all observable side effects are identical to a single merge.

YAML semantics for <<: are idempotent and commutative over duplicate sources,
so collapsing duplicates preserves behavior exactly; this isn't a spec trade-off.

PoC

Environment:
js-yaml version: 4.1.1
Node.js: v24.5.0
Platform: arm64 macOS (reproduced consistently)
Reproduction script:
Create many keys in one anchored map (&a).
Merge that same alias repeatedly via <<: [*a, *a, ...].
Measure parse time and compare with control payload using single merge (<<: *a).
Observed repeated runs (same machine):
K=M=1000, input 9,909 bytes: ~33–36 ms
K=M=2000, input 20,909 bytes: ~121–123 ms
K=M=4000, input 42,909 bytes: ~524–537 ms
K=M=6000, input 64,909 bytes: ~1,608–1,829 ms
K=M=8000, input 86,909 bytes: ~3,395–3,565 ms
Control (single merge, similar key counts):
K=2000: ~1–2 ms
K=4000: ~3 ms
K=8000: ~5 ms
Also verified: repeated-merge output equals single-merge output (same key count and same JSON), confirming excess time is redundant computation.

Impact

This is a denial-of-service vulnerability (CPU exhaustion / algorithmic complexity).
Any service parsing untrusted YAML with js-yaml can be impacted, including API backends, CI tools, config processors, and automation services. An attacker can submit crafted YAML to significantly increase CPU time and reduce availability.

Suggested fix:

Dedupe the merge source list by reference before invoking mergeMappings. Any of
the following are minimal and preserve YAML 1.1 merge semantics:

dedupe in storeMappingPair:

if (keyTag === 'tag:yaml.org,2002:merge') {
  if (Array.isArray(valueNode)) {
    var seen = new Set();
    for (index = 0, quantity = valueNode.length; index < quantity; index += 1) {
      var src = valueNode[index];
      if (seen.has(src)) continue;   // idempotent; skip redundant alias
      seen.add(src);
      mergeMappings(state, _result, src, overridableKeys);
    }
  } else {
    mergeMappings(state, _result, valueNode, overridableKeys);
  }
}</alert_description>

moderate</s...

• Resolves Azure/oav alert First version of cache builder and lookup logic for live validation #93

[mikeharder]

@copilot: Do we need to update package.json at all? Or can we just update package-lock.json, since js-yaml@4.2.0 is already compatible with ^4.1.0?

Also, why did you modify the test snapshot? Can you revert it, since it should unrelated to updated js-yaml?

[Copilot]

@copilot: Do we need to update package.json at all? Or can we just update package-lock.json, since js-yaml@4.2.0 is already compatible with ^4.1.0?

Also, why did you modify the...

Good questions — I investigated and reverted all three files (package.json, package-lock.json, and the snapshot) back to base in the latest commit. Findings:

package.json / lock: No change is needed, and the override is actively harmful, so I removed both:

• The direct js-yaml dependency already resolves to the patched 4.2.0 at base (it satisfies ^4.1.0), so nothing was needed there.
• The remaining vulnerable copies are transitive js-yaml@3.14.2 pulled in as ^3.13.1 by @azure/openapi-markdown (runtime), front-matter, and @istanbuljs/load-nyc-config. The overrides entry forced those to 4.2.0, but those packages call js-yaml.safeLoad, which was removed in js-yaml 4.x — so the override breaks them. A lock-only update can't fix the transitive copies either, since there is no patched 3.x release.

Snapshot: It turned out to be related, not unrelated — it was masking the regression. With the override in place, 7 of 8 readme-parsing tests in exampleGeneratorTests fail (readme YAML parses to empty), and the snapshot had been regenerated to match that broken output. After reverting the override and the snapshot, the full suite passes (8/8).

Net result of this commit: the PR is back to base (no diff). The transitive js-yaml@3.13.1 consumers can't be remediated without breaking runtime YAML parsing or an upstream bump of @azure/openapi-markdown / front-matter, so I'd defer to you on how to handle the alert (e.g. dismiss/suppress vs. wait for upstream).

[mikeharder]

@copilot: Why can't we just force consumers from js-yaml v3 to js-yaml 4.2.0? The APIs like safeLoad() were removed in v5, not 4.2.0.

I think we should just need one override "js-yaml": "^4.2.0", update lockfile, and everything should pass. Please try this.

[Copilot]

@copilot: Why can't we just force consumers from js-yaml v3 to js-yaml 4.2.0? The APIs like safeLoad() were removed in v5, not 4.2.0.

I think we should just need one override `"j...

I tried exactly this — added a single override "js-yaml": "^4.2.0", regenerated the lockfile (all transitive js-yaml now resolve to 4.2.0, no more 3.14.2), and ran the full suite. It still fails 7/8 in exampleGeneratorTests.

The premise that safeLoad() was only removed in v5 isn't quite right. In js-yaml@4.2.0, safeLoad is still exported as a function, but calling it throws:

$ node -e "require('js-yaml').safeLoad('a: 1')"
Function yaml.safeLoad is removed in js-yaml 4. Use yaml.load instead, which is now safe by default.

It was turned into a throwing stub in js-yaml 4.0.0, not v5. So typeof safeLoad === 'function' is true, but it's non-functional.

The concrete break is in @azure/openapi-markdown (getTagsToSettingsMapping), node_modules/@azure/openapi-markdown/dist/readMeManipulator.js:85:

try {
    settings = yaml.safeLoad(node.literal, {});  // throws under js-yaml 4.x
} catch (e) {
    return accumulator;                          // error swallowed → empty mapping
}

I reproduced it directly against the overridden node_modules: with js-yaml 4.2.0, getTagsToSettingsMapping(...) returns [], so getInputFilesForTag returns undefined, getInputFiles returns [], and validation reports no spec file specified — which is exactly the 7 failures. (front-matter@4.0.2 has the same issue at index.js:62, defaulting to parser.safeLoad.)

The latest @azure/openapi-markdown (0.9.4) still uses safeLoad, so there's no upstream-fixed version to bump to, and there's no patched 3.x js-yaml release either. I've reverted back to base (no net diff); full suite passes 8/8. Given that, the transitive alert can't be remediated purely via dependency resolution today without breaking runtime readme parsing — so it likely needs a suppression/dismissal or an upstream bump of @azure/openapi-markdown/front-matter. Happy to file/track that upstream if useful.