製品 Lemma API証明の発行・検証の基盤Trust402エージェントに任せ、取引するSeal鍵を渡さない、エージェント時代のサインイン
ユースケース 製造・基幹インフラ検査記録アシュアランス金融・FinTech取引先レコード検証自治体・公共証明書レス手続き医療・ヘルスケア有資格者アシュアランス調達・サプライチェーン仕入先資格モニタリングメディア・コンテンツコンテンツ真正性サービス・小売グループ横断アイデンティティAI導入（業種横断）AI実行ガバナンス開発者・エージェント運用エージェント権限統制 ▸ 業界別ソリューション索引を見る
料金
リソース Critical BriefAI×信頼の最前線ブログ考え方と実装の記録ドキュメントAPI と仕様書検証センター検証・発行の実数運営会社FRAME00, Inc.お問い合わせ導入・取材のご相談用語集言葉の定義FAQよくある質問
始める ↗ EN
ホーム / Critical Brief / No. 003
No. 003 Pillar 03 · エージェント権限証明

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

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

エージェント基盤 認証・認可
事案日
2026-05-27
公開日
2026-05-30
発行
Lemma Critical Team
関連 Pack
Pack A · Incident 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 にて影響サーバー特定用オンラインスキャナーが公開

事象は次の連鎖で成立している。

  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、産業機器)へ侵入

時系列 — 公表と対応

  • 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）として扱い、実環境での被害規模を誇張しない。

公表後の対応と業界の動きは次のとおり。

  • 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 サーバーが「すべての企業データへの蝶番」として配置されつつある現状を裏打ちする。

なぜ止まらなかったか

本事案は、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 検証が不可欠となる。

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

証明があれば、何が変わるか

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

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 検証として、検出層を置き換えるものではなく補完する。

Sources

「AI 時代のサイバー防衛に残された、最後の層」「Proof-as-Auth: 鍵を一度も送らずにサインインする」Pillar 03 — エージェント権限証明Trust402

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

この 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/
関連する BriefRelated
No. 139 LangChain・LangGraph・CrewAI など 6 つのエージェントフレームワークで 11 件の脆弱性が開示された エージェント基盤 No. 138 ServiceNow AI Platform で、未認証の 1 リクエストがコード実行・権限昇格・SQL 注入に届く脆弱性が 4 件開示された エージェント基盤 No. 133 同じ Pyodide サンドボックス脱出が 7 製品で再現されうることが示された エージェント基盤
Lemma

確かめられないものを、
業務に入れない。

Lemma は、データや AI の実行に暗号技術で証明を付け、受け取った側が発行者に問い合わせることなく真正性を確認できるようにします。検出はそのままに、その前段へ一層を足す構成です。

エンタープライズ相談 検証センターを見る