CVE-2026-59864 — Microsoft.OpenApi.Kiota
Fix: microsoft/kiota@9a18599CVE-2026-59864 is a Path Traversal vulnerability in Microsoft.OpenApi.Kiota. A fix is available for Microsoft.OpenApi.Kiota — see the affected versions and patch details below.
Kiota: Path/URL injection into generated Copilot plugin manifest via x-ai-* extensions
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-59864.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
Microsoft.OpenApi.Kiota.NETMicrosoft.OpenApi.Kiota.Builder.NETMicrosoft.OpenApi.Kiota.NETMicrosoft.OpenApi.Kiota.BuilderReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.
Description
Summary
kiota plugin add / kiota plugin generate (with -t APIPlugin) emits an attacker-controlled static_template.file path from the AI-plugin extensions (x-ai-adaptive-card, x-ai-capabilities) verbatim, with no path validation, into the generated Microsoft 365 Copilot / Teams plugin manifest (<name>-apiplugin.json). An attacker-controlled or compromised OpenAPI description can therefore embed a ../ / absolute path into the manifest's response_semantics.static_template.file, yielding a path traversal (CWE-22) / out-of-package file inclusion (CWE-829) that is resolved by the AI host when the generated plugin is deployed.
Confirmed on Kiota 1.32.4 (KIOTA_CONFIG_PREVIEW=true, the self-contained linux-x64 release binary).
Details
Both extension paths write the static_template.file reference straight into the manifest without sanitization — PluginsGenerationService.GetResponseSemanticsFromAdaptiveCardExtension mints static_template = {"file": <File>}, and the x-ai-capabilities path copies the static_template object through:
# spec -> generated manifest (functions[].capabilities.response_semantics)
x-ai-adaptive-card: {title: T, data_path: $.x,
file: "../../../../../../etc/passwd"} -> static_template.file = "../../../../../../etc/passwd" (CWE-22)
x-ai-capabilities.response_semantics.static_template:
{file: "../../../../../../etc/passwd"} -> static_template.file = "../../../../../../etc/passwd" (CWE-22)
(x-ai-adaptive-card.file only reaches the manifest when title is set, so GetResponseSemanticsFromAdaptiveCardExtension fires; otherwise kiota writes its own template card instead.)
Impact
This is not local code execution on the build host. The injected path is written into the generated plugin manifest and realized downstream, when the plugin is packaged and sideloaded / deployed to an AI host (Microsoft 365 Copilot / Teams) that resolves static_template.file relative to the plugin package (out-of-package file reference via ../). Kiota is the propagation point: it fails to reject ../ and absolute paths in this provider-supplied field before writing it into the manifest.
Patches
Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7892). static_template.file from both x-ai-adaptive-card and x-ai-capabilities is validated as a relative path confined to the plugin output package: absolute URIs, rooted/UNC paths, Windows drive paths, and .. traversal segments are rejected, and unsafe references are dropped with a warning. Regression tests cover .., absolute paths, and URI values.
Remediation
Upgrade to Kiota 1.29.1, 1.32.5 or later and regenerate affected plugins.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| .NETNuGet | Microsoft.OpenApi.Kiota | ≥ 1.30.0&&< 1.32.5 | 1.32.5dotnet add package Microsoft.OpenApi.Kiota --version 1.32.5 |
| .NETNuGet | Microsoft.OpenApi.Kiota.Builder | ≥ 1.30.0&&< 1.32.5 | 1.32.5dotnet add package Microsoft.OpenApi.Kiota.Builder --version 1.32.5 |
| .NETNuGet | Microsoft.OpenApi.Kiota | all versions | 1.29.1dotnet add package Microsoft.OpenApi.Kiota --version 1.29.1 |
| .NETNuGet | Microsoft.OpenApi.Kiota.Builder | all versions | 1.29.1dotnet add package Microsoft.OpenApi.Kiota.Builder --version 1.29.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for Microsoft.OpenApi.Kiota, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update Microsoft.OpenApi.Kiota to 1.32.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-59864 is resolved across your whole dependency graph.
Workarounds
Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.
Frequently Asked Questions
Is CVE-2026-59864 in your dependencies?
Find it across NuGet, including transitive dependencies.