Consumers stuck on Microsoft.OpenApi 2.x (via Microsoft.AspNetCore.OpenApi) cannot pick up Kiota.Builder security fixes past 1.29.0

[EelcoLos]

Description

Microsoft.OpenApi.Kiota.Builder 1.29.0 has 10 documented vulnerabilities on nuget.org, 2 critical, 8 high, all fixed in 1.32.5. The 2 critical ones are:

• GHSA-hq9q-27g5-qwpj, command injection via x-ms-kiota-info dependencyInstallCommand, surfaced by kiota info
• GHSA-4jwf-m4wg-8p66, path/URL injection into the generated Copilot plugin manifest via x-ai-* extensions

Since Microsoft.OpenApi.Kiota.Builder 1.30.0, the package has taken an exact dependency on Microsoft.OpenApi 3.x (currently 3.7.0 in 1.32.5). That's the right direction for Kiota itself, but it creates a hard wall for any project that also uses Microsoft.AspNetCore.OpenApi, which is still pinned to Microsoft.OpenApi 2.x and won't move to 3.x until ASP.NET Core 11 (tracked at dotnet/aspnetcore#67930, confirmed in the official breaking-changes doc: https://learn.microsoft.com/en-us/aspnet/core/breaking-changes/11/microsoft-openapi-3x). Anyone who also references Microsoft.AspNetCore.OpenApi in the same project cannot take the security fix.

To Reproduce

1. Reference Microsoft.OpenApi.Kiota.Builder 1.32.5 alongside Microsoft.AspNetCore.OpenApi 10.0.9 in the same project.
2. Build.

Expected behavior

Build succeeds, or at minimum the two packages' Microsoft.OpenApi major versions don't collide.

Actual behavior

Build fails with:

error CS0200: Property or indexer 'IOpenApiMediaType.Example' cannot be assigned to -- it is read only

because the AspNetCore.OpenApi source generator emits code against the mutable Microsoft.OpenApi 2.x interface, and 3.x made Example read-only. So consumers are stuck on Microsoft.OpenApi.Kiota.Builder 1.29.0, pre-dating all 10 fixes.

This is affecting FastEndpoints (see FastEndpoints/FastEndpoints#1101), which ships FastEndpoints.OpenApi.Kiota, referencing both packages in the same project, and is pinned to Kiota.Builder 1.29.0 as a result. For a visible example of the downstream Dependabot alerts this produces, see EelcoLos/nx-tinkering, a public repo consuming FastEndpoints: https://github.com/EelcoLos/nx-tinkering/security/dependabot

Versions

• Microsoft.OpenApi.Kiota.Builder: 1.29.0 (last version buildable alongside AspNetCore.OpenApi) vs 1.32.5 (has the fixes)
• Microsoft.AspNetCore.OpenApi: 10.0.9 (pinned to Microsoft.OpenApi 2.x until .NET 11)

Not asking Kiota to hold back the Microsoft.OpenApi 3.x move, that's clearly the right call long term. Opening this mainly so it's trackable from the Kiota side too, in case a backport of just the security fixes to a 1.29.x/1.3x line compatible with Microsoft.OpenApi 2.x is feasible, or so consumers waiting on ASP.NET Core 11 have somewhere to point to from this repo as well.

Related:

• The Microsoft.AspNetCore.OpenApi nuget package version 10.0.x nuget dependency to Microsoft.OpenApi v2.0.0 is incorrect and it should be constrained dotnet/aspnetcore#67930 (Microsoft.AspNetCore.OpenApi's Microsoft.OpenApi 2.x pin, root cause)
• FastEndpoints.ClientGen.Kiota dependency has CVE (Microsoft.OpenApi.Kiota.Builder < v1.32.5) FastEndpoints/FastEndpoints#1101 (downstream impact)

[pzimmerman-bmi]

This feels similar to #7966

[EelcoLos]

Following up with the actual ask: is a backport feasible at all, or is this a dead end?

Concretely: would a 1.29.x-compatible line that cherry-picks just the two critical fixes (GHSA-hq9q-27g5-qwpj, GHSA-4jwf-m4wg-8p66) onto the Microsoft.OpenApi 2.x API be something the team would consider merging/publishing, if someone put together that backport? Asking before anyone spends time isolating those two commits out of ~30 releases of unrelated 1.30-1.32 changes and revalidating against the 2.x interfaces, no point building a PR that's a non-starter on the maintenance-burden side.

If the answer is "wait for .NET 11", that's fine too, just want to know which one it is.

[pzimmerman-bmi]

Kiota team, any update on this?