Starletteの脆弱性BadHost、Hostヘッダーでパスによる認証の確認を回避されるおそれ。FastAPIを上げても古い版が残る場合の確かめ方

Starletteは、受け取った要求のURL（request.url）を、Hostヘッダーとパスをつないで組み立て直します。公式アドバイザリによると、1.0.0以前はこのときHostヘッダーを検証していませんでした。Hostに/、?、#などを含めると、組み立て直したURLのパスが、実際に要求されたパスとずれます。[1]

振り分け（ルーティング）は実際のパスで行われるため、本来のエンドポイントは動いたまま、request.url.pathだけが別のパスに見えます。特定のパスの下だけを守るミドルウェアがrequest.url.pathで判定していると、その確認を回避されるおそれがあります。[1]

公式は、前段のプロキシやロードバランサーが不正なHostを拒否または正規化し、かつアプリがX-Forwarded-Hostなど攻撃者が操作できるヘッダーを他の箇所で信頼していない場合に限り、影響が抑えられると説明しています。[1]

対象の版と影響する使い方は次のとおりです。

米国のCISAは2026年9月2日、CVE-2026-48710を「悪用が確認された脆弱性の一覧（KEV）」に追加しました。実際の攻撃で使われていることを示すため、優先して対応します。

発見者のX41 D-Secは、再現用のアプリと攻撃のコード（PoC）、検出用のスクリプトを公開しています。今後30日に悪用される見込みの推定（EPSS）は70.3%です（10月31日時点）。KEVの説明には、LiteLLMのコマンド実行の脆弱性（CVE-2026-42271、6月8日からKEV）と組み合わせられるおそれがあると書かれています。[4][5][6]

悪用が確認された脆弱性は、更新に加えて、更新前に攻撃を受けていないかを確認します。

1. 公開していた期間のWebサーバー・アプリケーションのログで、異常終了や不審な要求がないか確認します。
2. 見覚えのないファイル（Webシェルなど）や、設定・アカウントの変更がないか確認します。
3. サーバーから見覚えのない宛先への通信がないか確認します。
4. 痕跡が見つかった場合は、ログや機器の状態を保全し、専門の窓口に相談します。

1.0.1は、Hostヘッダーを規格（RFC 9112・RFC 3986）の文法で確かめ、不正な値のときは接続の情報（scope["server"]）を使うように直した版です。その後、パスの側からホスト名を偽れる低い深刻度の問題（GHSA-jp82-jpqv-5vv3）が1.3.0で、別の高い深刻度の問題（CVE-2026-54283など）が1.1.0と1.3.1で直っています。上げるなら1.3.1以上にします。[1][13][14]

0系には修正版が無いため、0.52.1以前からは1系への更新になります。1.0.0では、on_startup・on_shutdown、on_event()、@app.route()などの古い書き方が削除されました。Starletteを直接使っているアプリは、検証環境で起動と動作を確かめます。最新の1.10.0はPython 3.11以上が必要で、Python 3.10の環境には1.7.0までが入ります。[13]

1. 稼働中の環境で、Starletteの版と、どのパッケージが使っているか（Required-byの行）を確認します。

   ターミナル

   python -m pip show starlette

2. FastAPIの版も確認します。FastAPI 0.132系以前はStarletteを1.0.0未満に制限しているので、Starletteを1.0.1以上にするには、FastAPIを0.133.0以上にします。[7]

   ターミナル

   python -m pip show fastapi

3. lockファイルに記録された版を確認します。上のパッケージを更新しても、lockファイルのStarletteが古いままのことがあります。

   ターミナル

   grep -n -i -A1 'name = "starlette"' poetry.lock uv.lock
   grep -n -i 'starlette' requirements*.txt

4. Starletteを直接指定して上げます。FastAPIを使っている場合は一緒に指定します。uvやPoetryでは、lockファイルのStarletteだけを更新できます（使っているツールの行を実行します）。

   ターミナル

   python -m pip install --upgrade "starlette>=1.3.1" "fastapi>=0.133.0"
   uv lock --upgrade-package starlette
   poetry update starlette

5. 実際に読み込まれる版を確かめます。コードの中でrequest.url.pathで判定している箇所も探します。

   ターミナル

   python -c "import starlette; print(starlette.__version__)"
   grep -rn 'request.url.path' --include='*.py' .

Starletteのアドバイザリが示す対応は更新で、更新できないときの回避策は書かれていません（前段のプロキシで抑えられる条件は、影響を受ける条件の節のとおりです）。発見者のX41 D-Secは、パスではなくエンドポイントで認証すること、request.url.pathの代わりにrequest.scope["path"]を使うこと、不正なHostを拒否するリバースプロキシやASGIサーバーを置くことを挙げています。これは発見者の推奨で、Starletteが示した回避策ではありません。[1][2]

pipの--upgradeは、指定したパッケージを上げ、その依存は条件を満たしていればそのまま残します（初期設定のonly-if-needed）。FastAPIは、11月1日時点の最新版0.162.0でも、Starletteに0.46.0以上しか求めていません。そのため、古いStarletteが入った環境でFastAPIだけを上げても、Starletteは対象の版のまま残ります。[7][8]

逆に、上のパッケージが古いStarletteしか許さない場合もあります。PyPIに登録された依存の指定は次のとおりです。[7][9][10][11]

LiteLLMは1.84.0で、自分の認証の判定がStarletteの組み立て直したパスに頼っていた問題（CVE-2026-49468）を直しました。これはLiteLLM側の修正で、同じ環境のStarletteの版は変わりません。LiteLLMそのものの脆弱性と版の切り分けは、LiteLLMの脆弱性とバージョンの記事で説明しています。[12]

脆弱性の公表・更新一覧で、Pythonの関連情報を調べることもできます。