Microsoft.OpenApi.YamlReader vulnerable to denial of service via YAML alias expansionGHSA-7pxr-59rr-hqj2

Impact

A small YAML OpenAPI document containing nested anchors and aliases can cause uncontrolled resource consumption in Microsoft.OpenApi.YamlReader and Microsoft.OpenApi.Readers. The issue affects OpenAPI document parsing through the public YAML reader APIs and can cause the parsing process to allocate excessive memory and terminate through out-of-memory conditions.

Affected versions

Microsoft.OpenApi.YamlReader

• >= 2.0.0-preview.11, < 2.12.0
• >= 3.0.0, < 3.10.0

Microsoft.OpenApi.Readers

• < 1.6.30

Patches

• For the 1.X major version, versions 1.6.30 and above are patched.
• For the 2.X major version, versions 2.12.0 and above are patched.
• For the 3.X major version, versions 3.10.0 and above are patched.

Impact

Applications, CLIs, developer tools, or services that parse untrusted YAML OpenAPI documents in-process may be terminated by a crafted YAML document containing nested anchors and aliases.

The impact is availability/process termination only. This report does not claim remote code execution, authentication bypass, credential exposure, privilege escalation, data exposure, or Microsoft hosted service impact.

Details

Microsoft.OpenApi.YamlReader and Microsoft.OpenApi.Readers parses YAML through SharpYaml. SharpYaml represents aliases as shared YamlNode instances in a directed acyclic graph, so the initial parsed YAML graph remains small. During conversion to System.Text.Json.Nodes.JsonNode, aliases must be materialized as independent nodes because JsonNode instances cannot be attached to multiple parents.

Without a bound on that conversion work, a small YAML document using nested anchors and aliases can expand exponentially during conversion. With N nested anchors each referenced k times, conversion can require k^N materialized JSON nodes, leading to excessive memory allocation and possible process termination.

This is an uncontrolled resource consumption vulnerability, also known as a "billion laughs" style denial of service.

Example payload

openapi: 3.0.0
info:
  title: Test
  version: 0.0.1
paths: {}
x-a: &a ["lol", "lol", "lol", "lol", "lol", "lol", "lol", "lol", "lol"]
x-b: &b [*a, *a, *a, *a, *a, *a, *a, *a, *a]
x-c: &c [*b, *b, *b, *b, *b, *b, *b, *b, *b]
x-d: &d [*c, *c, *c, *c, *c, *c, *c, *c, *c]
x-e: &e [*d, *d, *d, *d, *d, *d, *d, *d, *d]
x-f: &f [*e, *e, *e, *e, *e, *e, *e, *e, *e]

Remediation

Users should upgrade to Microsoft.OpenApi.YamlReader 2.12.0 or 3.10.0, or Microsoft.OpenApi.Readers 1.6.30, depending on the major version line they consume.

The patched versions bound YAML-to-JSON conversion work and fail fast instead of allowing unbounded expansion. The default limits are:

• Maximum materialized node count: 5,000,000
• Maximum nesting depth: 64

When the limits are exceeded, OpenApiYamlReader.Read reports an OpenApiDiagnostic error and does not return a parsed document.

The limits are exposed as process-wide static properties on YamlConverter for consumers that need to tune them for trusted workloads:

• YamlConverter.MaxNodeCount
• YamlConverter.MaxDepth

Applications that parse OpenAPI documents from untrusted sources should avoid parsing those documents in the primary application process when possible. Running parsing in an isolated process can reduce the blast radius of parser failures.