Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
Miggo AIRoot Cause AnalysisThe vulnerability lies in the lack of sanitization for the clientClassName and clientNamespaceName properties, which can be provided via the x-ms-kiota-info OpenAPI extension or other configuration sources. An attacker could provide specially crafted values for these properties, containing path traversal sequences (../) or arbitrary code snippets. The Kiota tool would then use these unsanitized values to determine the output file path and to generate class and namespace declarations.
The analysis of the patch commit dc812dbbf88ef7edf53a890d36b2f9d1460e947d reveals that the fix involves introducing and applying sanitization functions at the points where these configuration values are read and processed. Specifically, the functions Kiota.Builder.LanguageInformation.Parse, Kiota.Builder.Configuration.GenerationConfiguration.UpdateConfigurationFromLanguagesInformation, and kiota.KiotaConfigurationExtensions.BindConfiguration were modified to use the new SanitizeClientClassName and SanitizeClientNamespaceName methods. These methods strip out characters that could be used for path traversal or code injection.
Therefore, the vulnerable functions are the ones that previously handled these configuration values without proper validation. During exploitation, a stack trace would likely show one of these functions processing the malicious input before it is used in file I/O operations or code generation, leading to the arbitrary file write or corrupted build.
Kiota.Builder.Configuration.GenerationConfiguration.UpdateConfigurationFromLanguagesInformationsrc/Kiota.Builder/Configuration/GenerationConfiguration.cs
Kiota.Builder.LanguageInformation.Parsesrc/Kiota.Builder/LanguageInformation.cs
kiota.KiotaConfigurationExtensions.BindConfigurationsrc/kiota/KiotaConfigurationExtensions.cs
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| Microsoft.OpenApi.Kiota | nuget | >= 1.30.0, < 1.32.5 | 1.32.5 |
| Microsoft.OpenApi.Kiota.Builder | nuget | >= 1.30.0, < 1.32.5 | 1.32.5 |
| Microsoft.OpenApi.Kiota | nuget | < 1.29.1 | 1.29.1 |
| Microsoft.OpenApi.Kiota.Builder | nuget | < 1.29.1 | 1.29.1 |
clientNamespaceNameA developer or CI host generating a client from an attacker-controlled or compromised OpenAPI description
(without -c) could create/overwrite a generated source file at an attacker-influenced path and emit
attacker-controlled text into the generated client.
This does not reach clean remote code execution: because clientClassName is reused verbatim at multiple
sites (the class name and the constructor name), injected code cannot be made to compile — it breaks the
build. So the code-injection vector is a generation/build-corruption (integrity/DoS), and the high-severity
primitive is the file write. CWE-22 / CWE-94.
Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7884). clientClassName and
clientNamespaceName sourced from x-ms-kiota-info are now sanitized before use:
GenerationConfiguration.SanitizeClientClassName strips any character outside [A-Za-z0-9_] and any invalid
leading character (falling back to ApiClient), and SanitizeClientNamespaceName restricts to
[A-Za-z0-9._-], collapses consecutive dots, strips invalid leading characters (falling back to ApiSdk).
This removes path separators, drive/colon, .., quotes, and braces, so the values can no longer influence
the output path or inject into the declaration.
Upgrade to Kiota 1.29.1, 1.32.5, or later and regenerate affected clients.