CVE-2026-105795: Kiota: Unsafe oauth_card_path references in Kiota-generated API plugin manifests
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 remains unvalidated through version 1.34.1, including the separate 1.29.1 security-backport release. Version 1.35.0 fixes the issue.
Patches
Upgrade to Kiota 1.35.0 or later and regenerate affected plugin manifests. Kiota now applies the existing safe-file-reference validator to oauthcardpath, drops unsafe references, and emits a warning. Valid relative card paths remain supported.
- Fix: https://github.com/microsoft/kiota/pull/8055 - Fixed release: https://github.com/microsoft/kiota/releases/tag/v1.35.0
Workarounds
Generate plugins only from trusted, integrity-protected OpenAPI descriptions. Before packaging or deployment, review generated manifests and remove any oauthcardpath that is not a safe relative reference confined to the plugin package. Do not rely on validation of sibling manifest fields to validate this field.
Related advisories
GHSA-4jwf-m4wg-8p66 and GHSA-p5rm-jg5c-8c77 cover statictemplate.file. Their fixes do not enforce validation at the separate oauthcardpath emission site.
Other sources
Kiota is an OpenAPI based HTTP Client code generator. From 1.25.1 until 1.35.0, Kiota copies x-ai-capabilities.responsesemantics.oauthcardpath from an attacker-controlled or compromised OpenAPI description into a generated API plugin manifest without validating that the value is a safe package-relative file reference. Parent-directory traversal, rooted paths, or absolute URIs can therefore reach a consuming host that resolves the reference, allowing the host to cross the intended plugin-package boundary or use an unintended authentication card. Kiota does not itself read a local file or execute code merely while generating the manifest, and impact requires downstream resolution of the unsafe reference. This issue is fixed in version 1.35.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
nuget/Microsoft.OpenApi.Kiota.Builderto a version that resolves this vulnerability.Fixed in 1.35.0 - Upgrade
Upgrade
nuget/Microsoft.OpenApi.Kiotato a version that resolves this vulnerability.Fixed in 1.35.0 - Upgrade
Upgrade
Microsoft.OpenApi.Kiota and Microsoft.OpenApi.Kiota.Builderto a version that resolves this vulnerability.Fixed in 1.35.0 - Configuration
Before packaging or deployment, review generated manifests and remove any oauth_card_path that is not a safe relative reference confined to the plugin package.
Kiota-generated API plugin manifests oauth_card_path = safe relative reference confined to the plugin package - Compensating control
Generate plugins only from trusted, integrity-protected OpenAPI descriptions.
- Operational
Regenerate affected plugin manifests after upgrading Kiota.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Organizations using Kiota to generate API plugin manifests from attacker-controlled or compromised OpenAPI descriptions are exposed if a downstream host resolves the generated oauth_card_path reference. Kiota generation alone does not read local files or execute code.
What must an attacker control for exploitation?
An attacker needs to supply or compromise an OpenAPI description containing x-ai-capabilities.response_semantics.oauth_card_path with a parent-directory traversal, rooted path, or absolute URI. A consuming host must then resolve that unsafe reference.
Are default Kiota-generated manifests affected?
The issue depends on the OpenAPI description containing the relevant oauth_card_path value and on downstream resolution of that value. The provided information does not indicate that ordinary manifests without such an attacker-controlled value are affected.
What should be done if an immediate upgrade is not possible?
Do not generate or consume plugin manifests from untrusted or potentially compromised OpenAPI descriptions that provide oauth_card_path values. Ensure consuming hosts reject parent-directory traversal, rooted paths, and absolute URIs, and only permit safe package-relative file references.
How can teams identify potentially affected generated manifests?
Inspect generated API plugin manifests for oauth_card_path references derived from x-ai-capabilities.response_semantics. Treat values containing parent-directory traversal, rooted paths, or absolute URIs as unsafe, particularly where a consuming host resolves them.