[GHSA-p5rm-jg5c-8c77] Microsoft Kiota: Path traversal in generated plugin manifest static_template.file reference (percent-encoding bypass)

[BarakSrour]

Updates

• Affected products

Comments
The advisory currently lists one affected product, Microsoft.OpenApi.Kiota. The vulnerable
validator ships in a second published package as well.

IsSafeFileReference is a member of Kiota.Builder.OpenApiExtensions.ExtensionResponseSemanticsStaticTemplate,
which lives in Kiota.Builder.dll. That assembly is published in two NuGet packages:

• Microsoft.OpenApi.Kiota - the .NET tool, which bundles it at tools/net10.0/any/Kiota.Builder.dll
• Microsoft.OpenApi.Kiota.Builder - the library, which ships it at lib/net8.0|net9.0|net10.0/Kiota.Builder.dll

Both the type and the method are public, so a consumer of the library package reaches the
vulnerable validator directly, and Kiota.Builder.Plugins.PluginsGenerationService - the class the
advisory names as the enforcement point - is public in that package too. A consumer who uses the
library to generate plugin manifests programmatically, rather than through the CLI, is affected on
the same code path.

Two things suggest this is an oversight rather than a scoping decision:

1. The advisory's own References section already points at that source tree: "Affected code:
   src/Kiota.Builder/OpenApiExtensions/OpenApiAiCapabilitiesExtension.cs (IsSafeFileReference)
   and enforcement in src/Kiota.Builder/Plugins/PluginsGenerationService.cs."
2. The earlier advisory for the same field in the same assembly lists both coordinates.
   GHSA-4jwf-m4wg-8p66 / CVE-2026-59864 - the fix that introduced IsSafeFileReference, which
   this advisory reports as bypassable — declares Microsoft.OpenApi.Kiota and
   Microsoft.OpenApi.Kiota.Builder. So the two advisories about one field currently disagree about
   which packages carry it.

Practical consequence: a dependency scanner reading this advisory clears
Microsoft.OpenApi.Kiota.Builder 1.33.0, which is affected.

Verification

Calling the published library package's own public validator, from a project that references it by
package name. Pure string predicate - no filesystem access, no network, no real path; the payload is
a marker filename that cannot exist.

// p.csproj: <PackageReference Include="Microsoft.OpenApi.Kiota.Builder" Version="1.33.0" />
using Kiota.Builder.OpenApiExtensions;
Console.WriteLine(ExtensionResponseSemanticsStaticTemplate.IsSafeFileReference(
    "%2e%2e/%2e%2e/KIOTA-BUILDER-MARKER.json"));

input	Microsoft.OpenApi.Kiota.Builder 1.33.0	1.34.0
%2e%2e/%2e%2e/KIOTA-BUILDER-MARKER.json	deemed_safe=True	deemed_safe=False
..%2f..%2fKIOTA-BUILDER-MARKER.json	deemed_safe=True	deemed_safe=False
../../KIOTA-BUILDER-MARKER.json (control)	deemed_safe=False	deemed_safe=False
cards/ok.json (control)	deemed_safe=True	deemed_safe=True

The two controls matter: the raw-traversal row confirms v1.32.5's original mitigation is present and
working in the library package (so this is specifically the percent-encoding bypass the advisory
describes, not the earlier CVE), and the benign row confirms the validator is not simply rejecting
everything. Assembly identity was read at runtime - Kiota.Builder 1.33.0.0 and 1.34.0.0.