Kiota CLI Command Injection: `kiota info` Let Malicious OpenAPI Specs Dictate Install Commands (CVE-2026-59865)

What Happened

Microsoft's GitHub Security Advisory GHSA-hq9q-27g5-qwpj discloses a command injection flaw in kiota info, tracked as CVE-2026-59865 and confirmed on Kiota 1.32.4. The kiota info command is meant to tell developers which packages to install after generating an API client. The bug: if an OpenAPI description contains an x-ms-kiota-info extension, kiota read the spec-supplied dependencyInstallCommand (plus dependency name/version) and presented it verbatim as its own trusted install-command suggestion — replacing kiota's normally safe, built-in recommendation.

According to the advisory, an attacker-controlled or tampered OpenAPI description could embed a malicious shell command (e.g. a curl | bash pipeline) in that field. A developer following kiota's own hint to "run the suggested install command" would then execute attacker-controlled shell. The kiota info --json output — consumed by the Kiota VS Code extension — carried the same raw command string, which the advisory notes could let an IDE "install dependencies" action run it automatically, without a manual copy-paste step.

Why It Matters

This is a supply-chain-adjacent risk for API client generation workflows rather than a running-service vulnerability: exploitation requires a developer or CI job to run kiota info against an untrusted or compromised OpenAPI description and then act on its suggested command. Given that OpenAPI specs are frequently pulled from third-party APIs, partner integrations, or public registries, the trust boundary here is easy to overlook. The advisory lists a public PoC as available, and the affected packages are Microsoft.OpenApi.Kiota and Microsoft.OpenApi.Kiota.Builder on NuGet. Impact ranges from workstation compromise to CI/CD host compromise (CWE-94, CWE-829), and automatic execution via the VS Code extension raises the risk of silent, low-interaction compromise for developers who trust the tooling's own hints.

What Defenders Should Watch For

• Inventory whether developers or CI pipelines run kiota (CLI or VS Code extension) against externally sourced or dynamically fetched OpenAPI descriptions.
• Treat OpenAPI/Swagger specs from external or partner sources as untrusted input — review before generating clients or accepting install-command suggestions.
• On developer workstations and CI runners, monitor for shell processes spawned as children of kiota, dotnet, or VS Code extension host processes, particularly network-fetch-then-execute patterns like curl | bash or iwr | iex.
• Audit CI logs for automated invocations of kiota info followed by unexpected outbound connections or package installs from unfamiliar package names/sources.
• Verify whether your environment's Kiota CLI and VS Code extension have been upgraded past the version tested vulnerable (1.32.4); the advisory states the fix removed spec-supplied install-command support entirely in 1.32.5.

Developing Intel

This writeup is based solely on the GitHub Security Advisory published 2026-07-24 and has not been independently verified beyond that source; details on real-world exploitation, if any, are not yet available. For the full technical writeup, patch PR reference, and remediation guidance, see the original advisory: github.com/microsoft/kiota/security/advisories/GHSA-hq9q-27g5-qwpj.