Summary
swagger-typescript-api trusts the OpenAPI servers[0].url field and embeds it directly into generated TypeScript HTTP client code without escaping.
When an attacker controls the OpenAPI spec, they can inject arbitrary TypeScript into the generated Fetch client, which executes as static initialization code on module import.
swagger-typescript-api trusts the OpenAPI servers[0].url field and embeds it directly into generated TypeScript HTTP client code without escaping.
When an attacker controls the OpenAPI spec, they can inject arbitrary TypeScript into the generated Fetch client, which executes as static initialization code on module import.
Affected context
This vulnerability manifests in workflows where API client code is generated automatically from OpenAPI specifications using swagger-typescript-api.
It is most relevant when:
- OpenAPI specs are sourced from untrusted or semi-trusted locations (e.g., third-party services, CI artifacts, or user uploads)
- Generated clients are checked into source control or consumed directly by applications without manual review
- The Fetch-based HTTP client template is used and the
servers[0].urlvalue influences the client base URL
This vulnerability manifests in workflows where API client code is generated automatically from OpenAPI specifications using swagger-typescript-api.
It is most relevant when:
- OpenAPI specs are sourced from untrusted or semi-trusted locations (e.g., third-party services, CI artifacts, or user uploads)
- Generated clients are checked into source control or consumed directly by applications without manual review
- The Fetch-based HTTP client template is used and the
servers[0].urlvalue influences the client base URL
Exploit preconditions
- Attack surface: The OpenAPI specification consumed by swagger-typescript-api (
servers[0].urlfield specifically). - Required access: Ability to supply or modify the OpenAPI document used for client generation (e.g., controlling an endpoint that emits OpenAPI, or tampering with spec files in build pipelines).
- Trigger point: Running swagger-typescript-api to generate a Fetch HTTP client and then importing the generated client module in a TypeScript or JavaScript runtime.
- Why exploitation is possible: The generator copies
servers[0].urldirectly intoapiConfig.baseUrl, and the Fetch client template interpolates this value into TypeScript source without escaping or validation, enabling injection of arbitrary static field code.
- Attack surface: The OpenAPI specification consumed by swagger-typescript-api (
servers[0].urlfield specifically). - Required access: Ability to supply or modify the OpenAPI document used for client generation (e.g., controlling an endpoint that emits OpenAPI, or tampering with spec files in build pipelines).
- Trigger point: Running swagger-typescript-api to generate a Fetch HTTP client and then importing the generated client module in a TypeScript or JavaScript runtime.
- Why exploitation is possible: The generator copies
servers[0].urldirectly intoapiConfig.baseUrl, and the Fetch client template interpolates this value into TypeScript source without escaping or validation, enabling injection of arbitrary static field code.
Why this happens
At its core, this is a code injection issue arising from unsanitized template interpolation of user-controlled data into generated source code.
The generator treats the OpenAPI servers[0].url value as a safe string and embeds it into the TypeScript client as part of a static field definition, without encoding, escaping, or separating data from executable code.
This aligns with CWE-94: Improper Control of Generation of Code, and is closely related to CWE-74: Injection and CWE-1336: Improper Neutralization of Special Elements in Template Engines, because structured template rendering is performed using attacker-controlled content.
At its core, this is a code injection issue arising from unsanitized template interpolation of user-controlled data into generated source code.
The generator treats the OpenAPI servers[0].url value as a safe string and embeds it into the TypeScript client as part of a static field definition, without encoding, escaping, or separating data from executable code.
This aligns with CWE-94: Improper Control of Generation of Code, and is closely related to CWE-74: Injection and CWE-1336: Improper Neutralization of Special Elements in Template Engines, because structured template rendering is performed using attacker-controlled content.
Potential impact
- Generated clients may execute attacker-controlled TypeScript or JavaScript code when imported.
- Build pipelines that compile or lint generated clients can run malicious logic during CI/CD.
- Applications consuming the generated client can be subverted, allowing data exfiltration or request manipulation.
- Developers' local environments may be impacted if they run tooling on compromised generated code.
- Downstream packages or repositories that include the generated client can propagate injected logic as a supply-chain risk.
- Generated clients may execute attacker-controlled TypeScript or JavaScript code when imported.
- Build pipelines that compile or lint generated clients can run malicious logic during CI/CD.
- Applications consuming the generated client can be subverted, allowing data exfiltration or request manipulation.
- Developers' local environments may be impacted if they run tooling on compromised generated code.
- Downstream packages or repositories that include the generated client can propagate injected logic as a supply-chain risk.
General mitigation guidance
Effective mitigation focuses on separating data from code in generation workflows and reducing trust in external specifications.
Typical patterns include:
- Enforcing strict validation and normalization of OpenAPI fields such as
servers[].urlbefore using them in templates. - Escaping or encoding interpolated values so they cannot break out of string or configuration contexts in generated code.
- Designing templates so that user-controlled inputs only appear in data literals (e.g., string constants, configuration objects) and never as raw code fragments.
- Restricting which specs can feed generation pipelines (e.g., signed specs, version-controlled sources) and applying least-privilege execution to build tooling.
- Adopting secure-by-default generators that treat external specifications as untrusted input and apply robust sanitization routines.
Effective mitigation focuses on separating data from code in generation workflows and reducing trust in external specifications.
Typical patterns include:
- Enforcing strict validation and normalization of OpenAPI fields such as
servers[].urlbefore using them in templates. - Escaping or encoding interpolated values so they cannot break out of string or configuration contexts in generated code.
- Designing templates so that user-controlled inputs only appear in data literals (e.g., string constants, configuration objects) and never as raw code fragments.
- Restricting which specs can feed generation pipelines (e.g., signed specs, version-controlled sources) and applying least-privilege execution to build tooling.
- Adopting secure-by-default generators that treat external specifications as untrusted input and apply robust sanitization routines.
How teams detect issues like this
Organizations can identify similar risks by:
- Reviewing code generators and templates for direct interpolation of untrusted fields into executable constructs (class definitions, static blocks, function bodies).
- Applying static analysis rules that flag generated source containing unusual tokens in configuration fields, such as unmatched quotes, template markers, or code keywords where URLs or identifiers are expected.
- Establishing policy checks in CI/CD that scan OpenAPI specs for malformed or non-standard values in structural fields like
servers[].url. - Using automated code review tools to highlight high-risk template usage and enforce guidelines around code generation inputs.
- Periodically auditing generated clients to confirm that dynamic content stays confined to well-formed data structures, not executable paths.
Organizations can identify similar risks by:
- Reviewing code generators and templates for direct interpolation of untrusted fields into executable constructs (class definitions, static blocks, function bodies).
- Applying static analysis rules that flag generated source containing unusual tokens in configuration fields, such as unmatched quotes, template markers, or code keywords where URLs or identifiers are expected.
- Establishing policy checks in CI/CD that scan OpenAPI specs for malformed or non-standard values in structural fields like
servers[].url. - Using automated code review tools to highlight high-risk template usage and enforce guidelines around code generation inputs.
- Periodically auditing generated clients to confirm that dynamic content stays confined to well-formed data structures, not executable paths.
