BadHost と呼ばれる脆弱性 CVE-2026-48710：FastAPI／Starlette ベースの AI サービスに深刻な影響

BadHost Vulnerability Exposes Sensitive AI Agent Server Endpoints to Attackers

2026/05/27 gbhackers — Starlette Web フレームワークに、”BadHost” と呼ばれる深刻な脆弱性 CVE-2026-48710 が確認され、数千件に及ぶ AI 搭載アプリケーション／API サービスが攻撃のリスクに晒されている。この脆弱性は、OSTIF が支援するセキュリティ監査の最中に X41 D-Sec が発見したものであり、悪用に成功した攻撃者に対して、サーバが受信するリクエストの操作を許すものである。それにより、認証制御のバイパスや機密エンドポイントへの不正アクセスを招く恐れがある。

Starlette は、FastAPI などの Python ベースの AI サービス基盤として広く使用されているため、この脆弱性の影響は AI エコシステム全体に及ぶものと考えられる。

BadHost 脆弱性の詳細

この問題の根本的な原因は、Starlette 旧バージョンの HTTP Host ヘッダー処理において、適切なサニタイズが欠落した状態で、ユーザー指定の Host ヘッダーから “request.url” オブジェクトが生成されていた点にある。

この不安全な挙動を突く攻撃者は、細工された悪意のリクエストを生成し、リクエストの解釈時に “request.url.path” 値の改変が可能となる。それによりアプリケーションが、悪意のルートやルーティングを正規のものとして誤認してしまう。その結果、管理用や内部向け API へのアクセス制御において、一般的に利用されるパス・ベース認証ミドルウェアが、有効な認証情報なしにバイパスされる可能性が生じる。

この脆弱性の影響は広範にわたるが、特に FastAPI や Starlette に大きく依存する AI インフラに対して深刻な被害をもたらす可能性がある。その対象に含まれるのは、vLLM／LiteLLM などの推論サーバや、Model Context Protocol (MCP) サーバ、OpenAI 互換 API、各種のカスタム AI エージェント・フレームワークなどである。

多くの導入環境において、機密エンドポイントが URL パス検証のみで保護されているため、この種の操作に対してきわめて脆弱である。そのため、BadHost を悪用する攻撃者は、制限された AI モデルへのアクセス取得／機密性の高いプロンプト・データの抽出／不正タスクを目的とした計算リソースの悪用などを実行する可能性がある。

脆弱性 CVE-2026-48710 の悪用は比較的容易であり、認証を必要としないことから深刻度が高まっていると、セキュリティ研究者たちは警告している。

実際の攻撃シナリオでは、特別に細工された Host ヘッダーを受信したバックエンド・サービスがリクエストを誤って解釈し、本来は公開されないはずの隠された内部エンドポイントが露出する可能性がある。この挙動により、セグメンテーションが不十分な AI インフラにおいて、AI 環境内でのラテラル・ムーブメントが容易になる恐れもある。

この問題に対処するために、ユーザーに対して強く推奨されるのは、この脆弱性へのパッチを取り込んでいる、Starlette 1.0.1 以降へと速やかにアップグレードすることだ。

さらに、アプリケーション層とリバースプロキシ層の両方で、Host ヘッダーの厳格な検証を実施することで、リスクの低減が可能になる。また、セキュリティ・チームは、パスベース・アクセス制御のみに依存することなく、多層的な認証メカニズムを採用する必要がある。それに加えて、Nemesis などが提供する自動スキャン・ツールは、公開状態にある AI エンドポイントや脆弱なデプロイメントをインフラ全体から特定する上で有効である。

脆弱性 BadHost が浮き彫りにするのは、従来型 Web アプリケーションの脆弱性と、現代 AI システムの融合に伴うリスクの拡大である。AI インフラが急速に拡大する中、リクエスト処理における僅かな設定ミスであっても、深刻なセキュリティ上の影響を招く可能性がある。これまで以上に、プロアクティブなパッチ適用と堅牢な入力検証の重要性が高まっている。

訳者後書：Starlette の脆弱性 CVE-2026-48710 (BadHost) は、プログラムがユーザーの入力を信じてしまうという問題に起因します。古いバージョンのフレームワークでは、送られてきた HTTP Host ヘッダーの安全性を確かめない状態で、プログラムの内部で使う URL オブジェクトを直接作っていました。この処理のギャップを突かれると、本来は入ることができない大切な場所に、正しい手続きなしでアクセスされてしまう危険性があります。ご利用のチームは、ご注意ください。