GHSA-4rj6-vrwv-wr8m

Summary

Microsoft Kiota honors a poisoned .kiota/workspace.json — the workspace configuration that Kiota's documented team workflow has developers commit to their repository — unvalidated on kiota client generate / kiota plugin generate. A repository (or pull request) containing a malicious per-client / per-plugin outputPath causes Kiota, when a developer or CI runs the documented regenerate command, to (CWE-22) write the entire generated client to an arbitrary path outside the workspace — the outputPath was not confined to the workspace root and absolute paths were accepted.

Confirmed on Kiota 1.32.4 (KIOTA_CONFIG_PREVIEW=true, the self-contained linux-x64 release binary).

Details

// .kiota/workspace.json (committed to the repo)
"clients": { "MyClient": {
   "outputPath": "/abs/path/outside/repo/pwned_client"   // -> generated client written here (CWE-22)
}}

Running kiota client generate --client-name MyClient in the repo writes MyClient.cs, P/PRequestBuilder.cs, … to the attacker-chosen outputPath (verified outside the working tree).

Note on descriptionLocation

The per-consumer descriptionLocation is intentionally fetched at generation time — this is how Kiota knows where to pull an updated description from when refreshing a client, the same way any other value in a committed lock/config file is honored. It is not treated as a vulnerability and is unchanged; only outputPath is now confined.

Impact

A malicious or compromised repository — or a malicious PR that edits .kiota/workspace.json — leads to arbitrary file write on the developer's or CI host's filesystem (overwrite source/build files, drop files in auto-loaded locations) whenever a teammate clones/pulls and runs the documented kiota client generate / kiota plugin generate to refresh the client. CWE-22.

This is a different trust boundary from the OpenAPI-description-based findings: the malicious input is the Kiota...