Arbitrary Code Injection Affecting microsoft.openapi.kiota.builder package, versions [,1.32.0)
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-DOTNET-MICROSOFTOPENAPIKIOTABUILDER-18021351
- published20 Jul 2026
- disclosed16 Jul 2026
- creditUnknown
Introduced: 16 Jul 2026
NewCVE-2026-59862 (opens in a new tab)How to fix?
Upgrade Microsoft.OpenApi.Kiota.Builder to version 1.32.0 or higher.
Overview
Affected versions of this package are vulnerable to Arbitrary Code Injection through PythonConventionService.RemoveInvalidDescriptionCharacters and KiotaBuilder enum description handling in src/Kiota.Builder/Writers/Python and src/Kiota.Builder/KiotaBuilder.cs. An attacker can execute arbitrary Python code at import time by supplying a malicious OpenAPI spec with x-ms-enum.values[].description containing newline characters that break out of generated comments or docstrings. The generated client files can then contain attacker-controlled top-level statements, so importing the SDK runs injected code in developer or CI environments.
Notes
- The vulnerable path is specific to generated Python clients that include
x-ms-enum.values[].descriptioncontent in emitted enum documentation; ordinary OpenAPI fields outside that generation path are not implicated. - Exploitation depends on a downstream workflow that generates code from an untrusted spec and then imports the resulting module, so environments that only inspect or package the generated files without importing them do not hit the runtime execution step.
Workarounds
- Only generate Python clients from trusted, internally controlled OpenAPI specification sources; do not generate from untrusted or attacker-controlled specs, because the exploit requires a malicious spec to inject code into generated modules.
- Disable or gate automatic client generation from remote specifications in CI/CD, so a malicious spec cannot flow into generation and then be imported by automation.
- Add validation or sanitization for
x-ms-enum.values[].descriptionbefore generation, so newline-bearing descriptions cannot escape comment/docstring context and become executable top-level Python. - Review generated Python files for suspicious top-level statements near enum and model declarations before importing them, to catch injected code before it runs.
- Run generation and validation in isolated environments without access to production secrets, limiting the impact if a malicious spec produces injected code.