Summary
Microsoft Kiota emitted the x-ms-kiota-info extension's clientClassName or clientNamespaceName value
raw, with no identifier or path sanitization, as both the generated client's class/namespace name
and part of the generated output path. When kiota generate is run without -c/--class-name — the
zero-config workflow that x-ms-kiota-info is explicitly designed for (the API provider supplies the names in
the description so consumers don't have to) — an attacker who controls or tampers with the OpenAPI description
could therefore:
- (CWE-22) write the generated source file to a path outside the
-o output directory — e.g.
clientClassName: "/var/www/html/shell"; and
- (CWE-94) inject arbitrary text into the generated class/namespace declaration, corrupting the generated
client.
Confirmed on Kiota 1.32.4 (the self-contained linux-x64 release binary), i.e. after the earlier
writer-sink hardening — that fix escaped property/enum/default/serialization sinks but never sanitized the
provider-supplied clientClassName / clientNamespaceName.
Details
clientClassName reached two unsanitized sinks (observed in the generated C#; the same raw emission occurred
for Java, Go, TypeScript, Python, and PHP):
# output FILENAME (CWE-22): clientClassName flows into the file path
clientClassName: "/abs/path/PWNED" -> /abs/path/PWNED.cs (written outside -o)
# class declaration (CWE-94): clientClassName flows verbatim into the type declaration
clientClassName: 'Pwn { } public class INJECTED { } public partial class RealClient'
-> public partial class Pwn { } public class INJECTED { } public partial class RealClient : ... { }
clientNamespaceName reached the analogous namespace/path sinks.
Impact
A 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.
Patches
Fixed in 1.32.5 (microsoft/kiota#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.
Remediation
Upgrade to Kiota 1.32.5 or later and regenerate affected clients.
References
Summary
Microsoft Kiota emitted the
x-ms-kiota-infoextension'sclientClassNameorclientNamespaceNamevalueraw, with no identifier or path sanitization, as both the generated client's class/namespace name
and part of the generated output path. When
kiota generateis run without-c/--class-name— thezero-config workflow that
x-ms-kiota-infois explicitly designed for (the API provider supplies the names inthe description so consumers don't have to) — an attacker who controls or tampers with the OpenAPI description
could therefore:
-ooutput directory — e.g.clientClassName: "/var/www/html/shell"; andclient.
Confirmed on Kiota 1.32.4 (the self-contained
linux-x64release binary), i.e. after the earlierwriter-sink hardening — that fix escaped property/enum/default/serialization sinks but never sanitized the
provider-supplied
clientClassName/clientNamespaceName.Details
clientClassNamereached two unsanitized sinks (observed in the generated C#; the same raw emission occurredfor Java, Go, TypeScript, Python, and PHP):
clientNamespaceNamereached the analogous namespace/path sinks.Impact
A 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 emitattacker-controlled text into the generated client.
This does not reach clean remote code execution: because
clientClassNameis reused verbatim at multiplesites (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.
Patches
Fixed in 1.32.5 (microsoft/kiota#7884).
clientClassNameandclientNamespaceNamesourced fromx-ms-kiota-infoare now sanitized before use:GenerationConfiguration.SanitizeClientClassNamestrips any character outside[A-Za-z0-9_]and any invalidleading character (falling back to
ApiClient), andSanitizeClientNamespaceNamerestricts to[A-Za-z0-9._-], collapses consecutive dots, strips invalid leading characters (falling back toApiSdk).This removes path separators, drive/colon,
.., quotes, and braces, so the values can no longer influencethe output path or inject into the declaration.
Remediation
Upgrade to Kiota 1.32.5 or later and regenerate affected clients.
References