GHSA-rg4h-fpcp-2qm8 is a high-severity (CVSS 7.1) Path Traversal vulnerability in Microsoft.OpenApi.Kiota. O3 Security confirms whether GHSA-rg4h-fpcp-2qm8 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Microsoft Kiota: Generation-time SSRF + remote/local file inclusion via unrestricted $ref
Real-World Exposure
Microsoft.OpenApi.Kiota.NETMicrosoft.OpenApi.Kiota.Builder.NETMicrosoft.OpenApi.Kiota.NETMicrosoft.OpenApi.Kiota.BuilderReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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 propertyREMOTE_KIOTA_PROPin the generated client.$ref: /abs/path.json#/...or../../secret.json#/...→ Kiota reads the out-of-tree local file and inlines its schema (LFI); confirmedLeakedschema 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.
Impact
Build-time SSRF (CWE-918) from the developer or CI host, disclosure of arbitrary local files (CWE-22), and inclusion of untrusted remote content (CWE-829), from running the generator on an attacker-controlled or attacker-influenced OpenAPI description. No code execution. Notable because Kiota is otherwise the hardened generator (it resists the code-injection class).
The relevant threat is not "change the generated output" (an attacker who fully controls the description can already do that) but the side effects on the build host: outbound requests from inside the CI network (cloud metadata, internal-only services) and reads of local files the attacker never possessed, whose contents are then inlined into the generated — and typically committed/published — client. It also bypasses controls that review the description document but not externally-referenced content.
Patches
Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7888). External reference resolution is now
default-deny: a new AllowedExternalOriginsStreamLoader refuses to load any external $ref — remote
http(s) URLs and local file paths alike — unless its origin/path is explicitly allow-listed. A new
--allowed-external-origins parameter (added to the commands that load OpenAPI descriptions) opts specific
origins back in, accepting *, full URIs, URI patterns, full paths, relative paths, or path patterns
(wildcards supported). With no allow-list entries, external references are not loaded at all.
Remediation
Upgrade to Kiota 1.29.1, 1.32.5, or later. External references now require explicit opt-in via
--allowed-external-origins; add only trusted origins/paths.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| .NETNuGet | Microsoft.OpenApi.Kiota | ≥ 1.30.0&&< 1.32.5 | 1.32.5 |
| .NETNuGet | Microsoft.OpenApi.Kiota.Builder | ≥ 1.30.0&&< 1.32.5 | 1.32.5 |
| .NETNuGet | Microsoft.OpenApi.Kiota | all versions | 1.29.1 |
| .NETNuGet | Microsoft.OpenApi.Kiota.Builder | all versions | 1.29.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for Microsoft.OpenApi.Kiota. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update Microsoft.OpenApi.Kiota to 1.32.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rg4h-fpcp-2qm8 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-rg4h-fpcp-2qm8 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-rg4h-fpcp-2qm8. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-rg4h-fpcp-2qm8 in your dependencies?
O3 detects GHSA-rg4h-fpcp-2qm8 across NuGet dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.