ホーム / Critical Brief / No. 003

Starlette（BadHost）：MCP サーバーの認証が Host ヘッダー操作で回避された

CVE-2026-48710 によるサーバー認証バイパス

Pillar 03 · エージェント権限証明 エージェント基盤 認証・認可
事案日
2026-05-27
公開日
2026-05-30
発行
Lemma Critical Team
関連 Pack
Pack AIncident Response

TL;DR

Starlette の CVE-2026-48710（BadHost）が公開された。Host ヘッダーへの 1 文字挿入で、ルーティングの解決パスとミドルウェアが見るパスが乖離し、パスベース認証を素通りできる。FastAPI / MCP サーバーなど Python AI 基盤の大半が影響を受ける。脆弱バージョンの検出は有用だが、パスベース認証自体が trust boundary を独立検証しておらず、修正パッチだけでは届かない。検出と事前証明は代替でなく補完である。

事案概要

  • 脆弱性 ID: CVE-2026-48710(別名 BadHost)
  • 公開日: 2026-05-27
  • 発見者: X41 D-Sec(マルクス・ヴェルヴィエ氏)
  • 影響範囲: Starlette および同フレームワーク上に構築された Python パッケージ群
    • 直接影響: FastAPI、vLLM、LiteLLM、Text Generation Inference
    • 間接影響: ほとんどの OpenAI 互換プロキシ、MCP サーバー、エージェントハーネス、評価ダッシュボード、モデル管理 UI
  • ダウンロード規模: Starlette 単体で週 3.25 億回(2026 年 5 月時点)
  • CVSS スコア: 7/10。X41 D-Sec と Secwest はいずれも「深刻度を著しく過小評価している」と評価
  • 修正版: Starlette 1.0.1 で対応済み
  • 検出ツール: mcp-scan.nemesis.services にて影響サーバー特定用オンラインスキャナーが公開
  • 核心: 本事案の構造的失敗は、ルーティングが解決するパスとパスベース認証が見るパスの乖離が認証層と独立検証されないまま放置され、Host ヘッダー操作だけで「認証済みか」という主張が事前検証なしに素通りした点にある。

タイムライン

  • 2026-05-27: X41 D-Sec が CVE-2026-48710 を公開、同日 Starlette 1.0.1 リリース
  • 2026-05-27: Ars Technica が初報、GIGAZINE が日本語で続報
  • 2026-05-27: X41 D-Sec が mcp-scan.nemesis.services オンラインスキャナーを公開
  • 2026-05-27: Secwest が「CVSS 評価は過小」とのコメントを公表

注: 固有名・CVE は一次（X41 D-Sec advisory・MITRE CVE・Starlette GitHub release 等）に基づき、各実装の対応状況は時点により異なるため最新情報を参照のこと。本 Brief は実証された構造的欠陥（CVE-2026-48710）として扱い、実環境での被害規模を誇張しない。

攻撃ベクター

  1. Initial compromise: 攻撃者は対象 MCP サーバーまたは Starlette 系アプリの公開 HTTP エンドポイントに通常通り HTTP リクエストを送信、ただし Host ヘッダーに 1 文字を意図的に挿入する
  2. Routing 動作の乖離: Starlette のルーティングアルゴリズムは HTTP path に依存して endpoint を解決する。一方、ミドルウェアやエンドポイントに提供される request.url.path 属性は「再構築された URL」に基づくため、HTTP で実際に要求されたパスと一致しない
  3. Authentication bypass: パスベース認証ミドルウェア(/admin 等へのアクセス制御)は request.url.path を見るが、ルーティングは実 HTTP path で endpoint を解決するため、middleware が通すパスと endpoint が解決するパスが分離する。認証を経ずに保護された endpoint に到達
  4. Credential exfiltration: 認証回避された MCP server が保管する外部リソース接続用認証情報(API キー、トークン、SSH 鍵、データベース接続文字列等)を奪取
  5. Lateral movement: 奪取した認証情報を用いて連結された外部システム(クラウド、データベース、メール、IoT、産業機器)へ侵入

構造的論点

本事案は、AI エージェントを動かす土台の HTTP layer(Starlette)において 「ルーティング解決パス ≠ ミドルウェアが見るパス」という構造的乖離が認証層と切り離されたまま放置されていた という構造の代表事例である。フレームワーク内部で trust boundary を独立に検証しない設計が、HTTP Host ヘッダーへの 1 文字挿入という最小限の入力操作で破壊される構造になっていた。

Brief 001(KelpDAO/rsETH)や Brief 002(Stake DAO)とは異なる primitive(対象が cross-chain message ではなく HTTP request)だが、両者に通底する構造は同じ:信頼の assertion(本事案ではパスベース認証)が、それを検証する layer と切り離されている。前者は cross-chain message の trust source、本事案は HTTP path の trust source。Trust boundary の独立検証不在という構造で同根。

検出と証明の落差

X41 D-Sec が公開した mcp-scan.nemesis.services は、影響を受けるサーバーを脆弱バージョン特定で検知する。これは「脆弱性が存在するか」の検出であり、運用上有用である。検出企業の役割が本 Brief で否定されるものではない。

一方、本脆弱性の根本は「パスベース認証という仕組み自体が trust boundary を独立検証していない」点にある。Starlette 1.0.1 の patch は当該乖離を修正するが、AI エージェントが外部リソースに HTTP 経由でアクセスする世界では、フレームワーク側のバグ修正に依存しない、より上位の trust boundary 検証が不可欠となる。

事前証明(pre-execution attestation)の文脈でこれを再構成すると、「エージェント / 認証主体 / 委任スコープ」を HTTP request 自体に独立検証可能な暗号証明として埋め込む設計が要求される。フレームワークが何を accept するかではなく、accept されるべきものが何かを別系統で証明する層が必要となる。X41 D-Sec が「CVSS 7 では過小評価」と表現した深刻度は、本質的にはこの構造的欠落の規模に由来する。

なお、Host ヘッダー操作による認証バイパスのような事案において、事後の検知・修正（detection）と、行動の前に出所・認可を独立検証する事前証明（pre-execution attestation）は代替ではなく 補完 の関係にある。MCP サーバーが外部リソースへアクセスする前に要求の正規性を証明することは、脆弱バージョンを検出する取り組みを置き換えるものではなく、これを補って機能するものである。

事後の検知が証明にならない論点は 「AI 時代のサイバー防衛に残された、最後の層」（Lemma、2026-05）、行動前に独立検証する設計は 「Proof-as-Auth: 鍵を一度も送らずにサインインする」（Lemma、2026-05）を参照。

対応経緯と業界動向

  • Starlette: バージョン 1.0.1 で BadHost 修正をリリース。request.url.path と実 HTTP path の整合性を回復
  • X41 D-Sec: mcp-scan.nemesis.services を公開、AI エージェントエコシステム横断のスキャン経路を提供
  • Secwest: CVSS 評価への警鐘
  • FastAPI / vLLM / LiteLLM / Text Generation Inference を採用するプロダクトには即時の依存関係 update が要請される。X41 D-Sec の指摘「深刻度は極めて高い」が示すように、特に MCP server を運用する組織は exposure 全面再評価が必要

X41 D-Sec が列挙した data at risk のカテゴリは、本事案の波及性を示す:バイオ医薬品 AI(臨床試験データベース、M&A データ、SSRF)、本人確認(顔分析、KYB、ライブ PII、内部コードベース)、IoT / 産業機器(踏み台経由 SSH、RCE)、メール / SaaS、人事 / 採用、CMS / マーケティング、文書管理、クラウド監視、サイバーセキュリティ(資産目録、ライブ核スキャナーアクセス)、個人の健康 / 財務データ。MCP サーバーが「すべての企業データへの蝶番」として配置されつつある現状を裏打ちする。

Lemma による分析

Lemma の設計は、エージェント / 認証主体 / 委任スコープを HTTP request 自体に証明として乗せる層の不在という本事案の gap に対し、受信側が path ではなく proof を見て accept 判定する点で対置される。

  • 行動前の認可証明(proof-as-auth): エージェントが外部リソースへ HTTP アクセスする時点で「誰が」「どの権限で」「どこまで」「どのリソースに対して」要求しているかを request 自体に独立検証可能な暗号証明として埋め込む。
  • スコープ付き権限: 委任スコープを proof に束ねることで、/admin 等の保護 endpoint への到達可否を path 解決ではなく権限の射程で判定できる。
  • フレームワークからの独立: framework 側の path 解決バグ（本事案の Host ヘッダー乖離）が存在しても、proof は別系統で「この request は正規の委任関係の下で生成された / 生成されていない」を告げる。
  • 検出との補完: 脆弱バージョンを検出する mcp-scan のような取り組みと、accept 前に要求の正規性を証明する層は、対立軸ではなく二段構成として機能する。

これは accept されるべきものが何かを別系統で証明する設計思想であり、フレームワーク側のバグ修正に依存しない上位の trust boundary 検証として、検出層を置き換えるものではなく補完する。

設計と適用範囲は、Pillar 03 — エージェント権限証明 および Trust402 を参照のこと。

Sources

Brief 配布について

本資料は公開情報の構造化分析であり、特定組織への監査・診断・推奨ではありません。

(c) 2026 FRAME00, INC. — Built for decisions that matter.

関連 Brief
エージェント基盤の全 27 件を見る
No. 073 · 2026-06-19

ShadowMQ：未認証 pickle を即実行する同一実装が AI 推論基盤に次々コピーされていた

再利用でエコシステム規模に広がった構造（Oligo Security）

エージェント基盤 コード来歴認証・認可
Brief →
No. 072 · 2026-06-19

Hugging Face LeRobot：未認証の通信で受け取ったデータを検証せず実行した

出所を検証しないデータを deserialize（pickle）した時点でコード実行に至る trust boundary 不在の構造（CVE-2026-25874）

エージェント基盤 認証・認可コード来歴
Brief →
No. 064 · 2026-06-16

Salesloft Drift：信頼された連携アプリの OAuth トークンが盗まれ、数百の Salesforce 環境が横断照会された

広範・永続の OAuth が、行動ごとにスコープ・失効検証されない構造（UNC6395）

エージェント基盤 認証・認可属性証明バイパス
Brief →
Cite this Brief

この Brief を引用する

Lemma Critical Team. (2026).
"Starlette（BadHost）：MCP サーバーの認証が Host ヘッダー操作で回避された — CVE-2026-48710 によるサーバー認証バイパス".
Lemma Critical Brief No.003. Lemma / FRAME00, Inc.
https://lemma.frame00.com/ja/critical/briefs/003-starlette-badhost/