Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
13 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact When generating an API plugin manifest from an attacker-controlled or compromised OpenAPI description, Kiota copies x-ai-capabilities.responsesemantics.oauthcardpath into the manifest without validating that it is a safe package-relative file reference. An attacker can supply parent-directory traversal, rooted paths, or absolute URIs instead of a card file within the plugin package. The unsafe reference is propagated into the generated manifest. Its security effect depends on the downstream host's handling of the reference when the plugin is packaged and deployed. This is not local code execution or a file read performed by Kiota merely during generation. A consuming host that resolves the untrusted reference can cross the intended package boundary or use an unintended authentication card. Affected versions The affected NuGet packages are Microsoft.OpenApi.Kiota and Microsoft.OpenApi.Kiota.Builder, starting with version 1.25.1, which introduced this manifest field. The field…
Recommended action: Upgrade to 1.35.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker who controls or tampers with an OpenAPI description can cause Kiota to emit attacker-controlled Java or PHP source outside a generated documentation comment. The affected sanitizers remove comment terminators rather than neutralizing them, allowing a terminator to reform from overlapping characters or from subsequent normalization. The Java sanitizer also removes non-ASCII characters after removing terminators, which can create a new terminator. Exploitation requires a developer or build pipeline to generate a client from the malicious description and subsequently compile and load the Java output, or load the PHP output. Code executes in the consuming application's or build environment's security context, not merely because Kiota reads the description. Affected versions The affected NuGet packages are Microsoft.OpenApi.Kiota and Microsoft.OpenApi.Kiota.Builder. The Java normalization-order defect was introduced in version 0.5.0 and remains present through version…
Recommended action: Upgrade to 1.35.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Kiota generates AI plugin manifests from an OpenAPI description. When the description contains an x-ai-capabilities response semantics statictemplate (or the adaptive-card extension x-ai-adaptive-card), the file reference is written into the generated manifest's responsesemantics.statictemplate.file and is later resolved by the AI host relative to the plugin package. 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 (CWE-22 Path Traversal, CWE-829 Inclusion of Functionality from an Untrusted Control Sphere). A mitigation shipped in v1.32.5 (ExtensionResponseSemanticsStaticTemplate.IsSafeFileReference) rejected literal traversal, rooted paths,…
Recommended action: Upgrade to 1.34.0 or 1.29.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.32.5 or 1.29.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 1.32.5 or 1.29.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 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…
Recommended action: Upgrade to 1.32.5 or 1.29.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.…
Recommended action: Upgrade to 1.32.5 or 1.29.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.32.5 or 1.29.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.32.4 or 1.29.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.32.0 or 1.29.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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()…
Recommended action: Upgrade to 1.32.0 or 1.29.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, <…
Recommended action: Upgrade to 1.32.3 or 1.29.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, <…
Recommended action: Upgrade to 1.31.1 or 1.29.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.