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 property REMOTE_KIOTA_PROP in the generated client.$ref: /abs/path.json#/... or ../../secret.json#/... → Kiota reads the out-of-tree local file and
inlines its schema (LFI); confirmed Leaked schema 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 (microsoft/kiota#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.
References
Gal3m Reporter
mrostamipoor Reporter
baywet Remediation developer
gavinbarron Remediation reviewer
Summary
Microsoft Kiota resolved OpenAPI
$refs by fetching remotehttp(s)URLs and reading local files(including absolute / out-of-tree paths), inlining the referenced schema into the generated client.
Running
kiota generateon a spec whose$refpointed at an attacker/internal URL or an arbitrarylocal 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 theremote schema (RFI); confirmed property
REMOTE_KIOTA_PROPin the generated client.$ref: /abs/path.json#/...or../../secret.json#/...→ Kiota reads the out-of-tree local file andinlines its schema (LFI); confirmed
Leakedschema in the generated client. Resolution is transitiveacross 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 (microsoft/kiota#7888). External reference resolution is now
default-deny: a new
AllowedExternalOriginsStreamLoaderrefuses to load any external$ref— remotehttp(s)URLs and local file paths alike — unless its origin/path is explicitly allow-listed. A new--allowed-external-originsparameter (added to the commands that load OpenAPI descriptions) opts specificorigins 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.References