Microsoft.OpenApi.YamlReader vulnerable to denial of service via YAML alias expansion

### 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 ```yaml 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.