Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-4rj6-vrwv-wr8m
No affected components available
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 config, not the spec.
Patches
Fixed in 1.32.5 (https://github.com/microsoft/kiota/pull/7885). On loading a workspace configuration,
each client/plugin outputPath is validated to be a relative subdirectory of the workspace: null/empty,
rooted paths (POSIX /, UNC \\ / //, Windows drive X:\), and any .. traversal segment are rejected,
and the resolved full path must stay under the workspace root. Generation aborts with an error if any
consumer's outputPath escapes the workspace.
Remediation
Upgrade to Kiota 1.32.5 or later. Review any committed workspace configs for outputPath values that
point outside the workspace.
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights.
Exploitation attempts have been detected. Elevated vigilance and prompt remediation are advised.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard