Summary
swagger-typescript-api improperly injects attacker-controlled OpenAPI path strings into JavaScript template literals when generating client methods, without escaping interpolation syntax.
If an API specification contains a path with ${...}, arbitrary JavaScript can execute when the generated client method runs, enabling high-impact code injection in consuming applications.
swagger-typescript-api improperly injects attacker-controlled OpenAPI path strings into JavaScript template literals when generating client methods, without escaping interpolation syntax.
If an API specification contains a path with ${...}, arbitrary JavaScript can execute when the generated client method runs, enabling high-impact code injection in consuming applications.
Affected context
This vulnerability affects projects that:
- Use swagger-typescript-api to generate TypeScript API clients for Fetch or Axios
- Consume OpenAPI specifications that may include untrusted or externally supplied path definitions
- Compile and run the generated client code in production or development environments
The issue appears in the route name handling logic where OpenAPI path keys are transformed and inserted into JavaScript template literals in EJS templates without proper escaping of ${...} sequences.
This vulnerability affects projects that:
- Use swagger-typescript-api to generate TypeScript API clients for Fetch or Axios
- Consume OpenAPI specifications that may include untrusted or externally supplied path definitions
- Compile and run the generated client code in production or development environments
The issue appears in the route name handling logic where OpenAPI path keys are transformed and inserted into JavaScript template literals in EJS templates without proper escaping of ${...} sequences.
Exploit preconditions
- Attack surface: The OpenAPI specification file or definition used as input to swagger-typescript-api.
- Required access: Ability to add or modify paths in the OpenAPI spec (e.g., via compromised spec repository, malicious upstream service definition, or supply-chain manipulation).
- Trigger point: Execution of a generated client method whose name or internal logic derives from a path containing
${...}. - Why exploitation is possible: Path keys are passed through
parseRouteNameinto EJS templates and emitted as JavaScript template literals without escaping interpolation, turning crafted spec content into executable code inside the generated client.
- Attack surface: The OpenAPI specification file or definition used as input to swagger-typescript-api.
- Required access: Ability to add or modify paths in the OpenAPI spec (e.g., via compromised spec repository, malicious upstream service definition, or supply-chain manipulation).
- Trigger point: Execution of a generated client method whose name or internal logic derives from a path containing
${...}. - Why exploitation is possible: Path keys are passed through
parseRouteNameinto EJS templates and emitted as JavaScript template literals without escaping interpolation, turning crafted spec content into executable code inside the generated client.
Why this happens
The underlying bug is a failure to treat OpenAPI specification content as untrusted data when embedding it into source code.
In swagger-typescript-api, path strings are fed into EJS templates that output JavaScript/TypeScript methods using template literals. Because ${...} sequences in the path are not escaped or sanitized, they are interpreted as JavaScript expressions at runtime.
This maps to CWE-94: Code Injection, where user-controlled input is incorporated into executable code; CWE-74: Improper Neutralization of Data within a Different Syntax Region, because data crosses from specification text into JavaScript syntax; and CWE-1336: Improper Neutralization for Alternate Syntax, as template literal semantics are not correctly accounted for when generating code.
The underlying bug is a failure to treat OpenAPI specification content as untrusted data when embedding it into source code.
In swagger-typescript-api, path strings are fed into EJS templates that output JavaScript/TypeScript methods using template literals. Because ${...} sequences in the path are not escaped or sanitized, they are interpreted as JavaScript expressions at runtime.
This maps to CWE-94: Code Injection, where user-controlled input is incorporated into executable code; CWE-74: Improper Neutralization of Data within a Different Syntax Region, because data crosses from specification text into JavaScript syntax; and CWE-1336: Improper Neutralization for Alternate Syntax, as template literal semantics are not correctly accounted for when generating code.
Potential impact
- Generated client methods may execute arbitrary JavaScript provided via the OpenAPI spec.
- Attackers could access application secrets, environment variables, or sensitive data available to the client runtime.
- Malicious code can alter request parameters or responses, enabling data exfiltration or tampering.
- The compromised client library can serve as an entry point for broader application compromise or supply-chain attacks.
- Generated client methods may execute arbitrary JavaScript provided via the OpenAPI spec.
- Attackers could access application secrets, environment variables, or sensitive data available to the client runtime.
- Malicious code can alter request parameters or responses, enabling data exfiltration or tampering.
- The compromised client library can serve as an entry point for broader application compromise or supply-chain attacks.
General mitigation guidance
Effective mitigation focuses on separating data from code during client generation and enforcing strict neutralization of specification content:
- Treat all OpenAPI paths, operation IDs, and descriptions as untrusted data when embedding into generated code.
- Escape or sanitize characters that have special meaning in JavaScript template literals, particularly
${and backticks, before inserting them into source templates. - Use code-generation patterns that avoid executing or dynamically evaluating generated strings at runtime, preferring static methods and safe string concatenation.
- Constrain trust boundaries by limiting who can modify OpenAPI specifications and by reviewing changes to spec files with the same rigor as code changes.
- Apply least-privilege principles to environments where generated clients run so that, even if injection occurs, the runtime has reduced access to sensitive resources.
Effective mitigation focuses on separating data from code during client generation and enforcing strict neutralization of specification content:
- Treat all OpenAPI paths, operation IDs, and descriptions as untrusted data when embedding into generated code.
- Escape or sanitize characters that have special meaning in JavaScript template literals, particularly
${and backticks, before inserting them into source templates. - Use code-generation patterns that avoid executing or dynamically evaluating generated strings at runtime, preferring static methods and safe string concatenation.
- Constrain trust boundaries by limiting who can modify OpenAPI specifications and by reviewing changes to spec files with the same rigor as code changes.
- Apply least-privilege principles to environments where generated clients run so that, even if injection occurs, the runtime has reduced access to sensitive resources.
How teams detect issues like this
Teams can identify similar vulnerabilities using:
- Static analysis rules or custom linters that flag code-generation paths where template literals or string interpolation directly incorporate untrusted specification content.
- Code review practices that treat EJS or other templating files as security-sensitive, checking for proper escaping functions around all spec-derived values.
- Repository policies that require security review for changes to OpenAPI specs, generator templates, and parsing utilities like
parseRouteName. - Automated build-time checks that scan generated output for
${sequences originating from spec content, indicating potential injection vectors.
Teams can identify similar vulnerabilities using:
- Static analysis rules or custom linters that flag code-generation paths where template literals or string interpolation directly incorporate untrusted specification content.
- Code review practices that treat EJS or other templating files as security-sensitive, checking for proper escaping functions around all spec-derived values.
- Repository policies that require security review for changes to OpenAPI specs, generator templates, and parsing utilities like
parseRouteName. - Automated build-time checks that scan generated output for
${sequences originating from spec content, indicating potential injection vectors.
