Summary
OpenAPI3 version value escapes emitterOutputDir and overwrites YAML/JSON outside the output tree
The @typespec/openapi3 emitter retains the value of a @versioned enum member and interpolates it into the output filename as {version} without sanitizing path separators or traversal components. The completed path reaches the compiler's emitFile(), which creates the parent directory and writes the file without verifying containment under emitterOutputDir.
A crafted declarative .tsp input can therefore create or overwrite an OpenAPI-formatted .yaml or .json file outside the configured output tree, subject to the compiler process's filesystem permissions. No executable TypeSpec extension or attacker-controlled JavaScript is required.
Affected version
Confirmed on:
@typespec/compiler1.15.0@typespec/openapi31.15.0@typespec/http1.15.0@typespec/versioning0.85.0- release tag commit
f30cd352f93997e04c75d48c7ace6947a1d5d07a
The critical openapi.ts and emitter-utils.ts blobs are unchanged on main commit 365ec52b50b82cd9e1e037de4c6fcd5de7e32e90 as checked on 2026-08-19. No patched version was identified.
Root cause
The value originates at packages/openapi3/src/openapi.ts:592-608:
serviceRecord.versions.push({
service,
version: snapshot.version!.value,
document: document[0],
diagnostics: document[1],
});
It is interpolated without path validation at openapi.ts:629-641:
return interpolatePath(options.outputFile, {
"openapi-version": specVersion,
"service-name-if-multiple": multipleService ? getNamespaceFullName(service.type) : undefined,
"service-name": getNamespaceFullName(service.type),
"file-type": fileType,
version,
});
The path reaches emitFile() at openapi.ts:392-401. The sink at packages/compiler/src/core/emitter-utils.ts:29-39 performs no output-root containment check:
const outputFolder = getDirectoryPath(options.path);
await program.host.mkdirp(outputFolder);
return await program.host.writeFile(options.path, content);
resolvePath() joins the template to emitterOutputDir before {version} is interpolated, so it does not see the attacker-controlled .. components.
Proof of concept
The relevant input in poc/main.tsp is:
@versioned(Versions) namespace Svc;
enum Versions { v1: "../../../../../../../../../../tmp/TYPESPEC_PWNED/pwn" }
Run from PowerShell:
cd poc
.\run-revalidation.ps1
The supplied Docker runner uses a digest-pinned Node base, a committed npm integrity lock, disabled runtime networking, a benign control, a 90-second timeout, and cleanup enforcement.
Observed in the preserved identity-locked replay (1/1 attack and 1/1 negative control):
negative_before=02dc7d056c2f773e56e2c1849947888b039f127ddd630c0bd76a5d7a9ca29cbd
negative_after=02dc7d056c2f773e56e2c1849947888b039f127ddd630c0bd76a5d7a9ca29cbd
attack_before=7a8067bc04e42a025de90fd7aff9be4df59f005d192f2116eecfb107d7bffd78
attack_after=2992b399c1573c9bd2130794f8554c4026bf425861f74e78b5d89ae0324b5e38
outside_file_head=openapi: 3.0.0
inside_attack_files=
The benign version preserved the outside canary. The crafted version replaced it with emitted OpenAPI content, and no attack output file remained under tsp-output.
Impact and constraints
Proven impact is out-of-directory YAML/JSON creation or overwrite. The attacker can influence the traversal, final basename, and many strings in the OpenAPI-structured content. The extension is constrained to the selected emitter format, content is not arbitrary bytes, and the target must be writable.
This report demonstrates file corruption. Denial of service is a potential impact when a writable critical file is targeted. It does not claim file disclosure, arbitrary-byte write, deployment takeover, or code execution by a downstream consumer.
Suggested remediation
After every filename token has been interpolated, resolve the completed destination against emitterOutputDir and reject any non-descendant using path-component-aware comparison. Reject or slugify absolute paths, path separators, and traversal components in spec-derived filename tokens. Add regression cases for POSIX and Windows separators, absolute values, sibling-prefix paths, and benign semantic versions.
Impact
Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.
GHSA-2Q42-4Q24-7RGV has a CVSS score of 7.1 (High). The vector is requires local access, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. No fixed version is listed yet, so configuration controls and monitoring matter more in the interim.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
In the interim: Resolve the canonical path after applying any user-supplied input, and verify it remains within the intended directory before accessing it.
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-2Q42-4Q24-7RGV? GHSA-2Q42-4Q24-7RGV is a high-severity path traversal vulnerability in @typespec/openapi3 (npm), affecting versions <= 1.15.0. No fixed version is listed yet. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
- How severe is GHSA-2Q42-4Q24-7RGV? GHSA-2Q42-4Q24-7RGV has a CVSS score of 7.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which packages are affected by GHSA-2Q42-4Q24-7RGV?
@typespec/openapi3(npm) (versions <= 1.15.0)@typespec/compiler(npm) (versions <= 1.15.0)
- Is there a fix for GHSA-2Q42-4Q24-7RGV? No fixed version is listed for GHSA-2Q42-4Q24-7RGV yet. Monitor the advisory for updates and apply mitigations in the interim.
- Is GHSA-2Q42-4Q24-7RGV exploitable, and should I be worried? Whether GHSA-2Q42-4Q24-7RGV is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-2Q42-4Q24-7RGV is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-2Q42-4Q24-7RGV? No fixed version is listed yet. In the interim: Resolve the canonical path after applying any user-supplied input, and verify it remains within the intended directory before accessing it.