CVE-2026-59864: Critical Out-of-Package Local File Inclusion in Microsoft Kiota

Microsoft Kiota is an OpenAPI-based HTTP client and plugin code generator designed to streamline the integration of external APIs into application ecosystems, including Microsoft 365 Copilot and Microsoft Teams plugins. During the compilation of plugins via commands such as kiota plugin add or kiota plugin generate with the target parameter set to APIPlugin, Kiota parses incoming OpenAPI description documents to extract endpoints, capabilities, and presentation layers. This process exposes an attack surface centered on the parser's ingestion of custom OpenAPI extensions supplied by the document designer.

The vulnerability, tracked as CVE-2026-59864, is classified as an improper limitation of a pathname to a restricted directory (CWE-22) combined with the inclusion of functionality from an untrusted control sphere (CWE-829). The security flaw exists within the parsing and processing of custom Microsoft-specific AI extensions: x-ai-adaptive-card and x-ai-capabilities. These schema extensions allow developers to link to external adaptive card templates and runtime specifications, but Kiota historically did not validate the target locations of these linked assets.

When a developer uses a vulnerable version of Kiota to process a maliciously crafted OpenAPI specification, the tool outputs a plugin manifest file (<name>-apiplugin.json) that carries the unvalidated directory traversal payload. When this output manifest is later sideloaded or deployed into an execution environment, such as Microsoft 365 Copilot or Microsoft Teams, the runtime host attempts to load the defined file relative to the plugin package directory. Because the path is not restricted, the host traverses the local filesystem, leading to unauthorized read-access of arbitrary host-level configurations and system files.

The underlying cause of CVE-2026-59864 lies in a fundamental trust boundary violation within Kiota's generation pipeline. In the affected versions, PluginsGenerationService.cs acts as the coordinator that transforms OpenAPI metadata into JSON structures used by Microsoft 365 Copilot. When processing the custom keys x-ai-adaptive-card and x-ai-capabilities, the service extracts the string parameter associated with the property path response_semantics.static_template.file.

The parsing service assumed that all file paths specified in the OpenAPI specification were benign, local, and relative to the generation workspace. No schema validation or boundary checks were executed against this parameter. Consequently, string inputs containing directory traversal sequences (such as ../ or ..\\), absolute local paths, or network-based file locations were accepted without modification.

These path strings were compiled directly into the resulting plugin manifest file. This structure delegates the file resolution responsibility to the downstream runtime host. When the execution host loads the deployment package, it parses the manifest, identifies the file reference, and resolves it. Because the input was not sanitized during compilation, the host executes the traversal commands, moving beyond the plugin's sandbox directory and accessing the host system's file system directly under the privileges of the active application process.

Prior to the release of version 1.32.5, Kiota had no security layers validating file references extracted from parsed OpenAPI documents. The tool recursively scanned incoming JSON or YAML nodes and directly serialized them into the manifest stream. The fix, introduced in commit 9a185994a4e549b7bba3cc2beffb9736aa902e79, establishes the ExtensionResponseSemanticsStaticTemplate validation class to enforce safe, relative path parameters.

Below is the logic implemented in the patch to validate the incoming file references:

public class ExtensionResponseSemanticsStaticTemplate
{
    public JsonObject Template { get; init; } = new();
 
    public string? File =>
        Template.TryGetPropertyValue("file", out var fileNode) &&
        fileNode is JsonValue fileValue &&
        fileValue.TryGetValue<string>(out var file)
            ? file
            : null;
 
    public bool HasUnsafeFileReference => File is not null && !IsSafeFileReference(File);
 
    public static bool IsSafeFileReference(string? file)
    {
        if (string.IsNullOrWhiteSpace(file))
        {
            return false;
        }
 
        // 1. Reject absolute URIs (e.g., http://, file://, ftp://)
        if (Uri.TryCreate(file, UriKind.Absolute, out _))
        {
            return false;
        }
 
        // Normalize directory separators for cross-platform validation
        var normalized = file.Replace('\\', '/');
 
        // 2. Reject POSIX-absolute and UNC-style rooted paths
        if (normalized.StartsWith('/'))
        {
            return false;
        }
 
        // 3. Reject Windows drive-qualified paths (e.g. C:\)
        if (normalized.Length >= 2 && normalized[1] == ':')
        {
            return false;
        }
 
        // 4. Reject parent directory traversal segments (..)
        foreach (var segment in normalized.Split('/'))
        {
            if (segment == "..")
            {
                return false;
            }
        }
 
        return true;
    }
}

The implementation targets key evasion techniques. Converting backslashes (\\) to forward slashes (/) handles Windows-specific and POSIX-specific paths uniformly. Splitting by / and verifying each individual segment ensures that partial matches or complex relative structures (e.g., .../ or nested directories containing double dots) are evaluated. If HasUnsafeFileReference returns true, the code omits the invalid reference and issues a warning, which prevents the compiler from emitting malicious parameters to the generated output JSON.

To exploit this vulnerability, an attacker must first draft a malicious OpenAPI specification document containing a targeted path traversal sequence within the Microsoft AI extensions. The attacker then distributes this document to target developers or automates its delivery through package registries, public APIs, or social engineering. The developer compiles the document using the local Kiota CLI.

When Kiota parses this document, it propagates the string literal ../../../../../../etc/passwd or a Windows-specific path such as ..\\..\\..\\windows\\system32\\config\\sam into the final manifest file without raising an error. Once the compiled manifest is bundled into a plugin package and uploaded to an enterprise's Microsoft 365 Copilot execution tenant, the host service parses the plugin specifications. The execution engine attempts to locate the Adaptive Card or capabilities file using the defined directory traversal instructions, reading files outside the sandbox and returning their contents to the calling context.

The impact of successful exploitation is high, as reflected by the CVSS 4.0 base score of 9.3. The severity is driven by the potential for remote, unauthenticated attackers to obtain high-privilege read access to the local filesystem of downstream runtime hosts. This bypasses structural application container boundaries, turning a presentation-layer card rendering feature into a vector for local file disclosure.

The vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N indicates that network access is sufficient to deliver the exploit, no special architectural barriers exist, and the outcome has a high impact on confidentiality, integrity, and availability. Compromising these environments can expose sensitive administrative credentials, cryptographic secrets, database configuration files, and internal network maps, allowing attackers to plan secondary internal network propagation campaigns.

A detailed evaluation of the validation routines in version 1.32.5 reveals that while the sanitization of relative directory steps is thorough, defensive engineers must monitor the execution paths of downstream hosts. If a downstream runtime host performs URL decoding or parsing on the static_template.file string after extracting it from the manifest JSON, double-encoded traversal sequences like %252e%252e%252f could potentially bypass the initial compiler checks.

Additionally, validation relies on the strict identification of double-dot (..) segments. If the downstream file parser processes alternative Unicode normalization forms (such as transforming fullwidth characters like ．．／ into standard ../ segments) and Kiota does not enforce Unicode normalization before running its boundary checks, a validation bypass remains possible. Downstream AI hosts must employ defense-in-depth measures, enforcing absolute path checks at the runtime layer to ensure that the resolved path does not leave the boundary of the isolated application directory.

Remediation requires immediately upgrading the Microsoft Kiota compiler toolchain and its associated development libraries to version 1.32.5 or higher. Developers can update the globally installed dotnet tool by running dotnet tool update -g Microsoft.OpenAPI.Kiota in their command terminals.

For enterprise environments unable to perform immediate upgrades, manual validation controls must be implemented at the gateway or deployment level. All custom OpenAPI files should be scanned for the presence of x-ai-capabilities and x-ai-adaptive-card extensions, and any containing the literal character sequences .. or leading slashes in file parameters should be blocked. Additionally, security teams must inspect generated output manifests for path traversal sequences before approving plugin packages for tenant deployment.