CISA（米国サイバーセキュリティ・インフラセキュリティ庁）が2026年9月2日、AIゲートウェイ LiteLLM と、Pythonの ASGI フレームワーク Starlette の脆弱性を悪用確認済み脆弱性カタログ（KEV）へ追加しました。
まず結論から。LiteLLM は 1.84.0 以降、Starlette は 1.0.1 以降へ更新してください。 LiteLLM を外部に公開している場合は、更新より先に `/mcp/` へのアクセス遮断が効きます（開発元が公式に示している回避策です）。
この記事は2026年9月3日時点で、CISA KEV・NVD・開発元のGitHubセキュリティアドバイザリで裏が取れた内容だけをまとめています。
今すぐ行う対策
- ✓LiteLLM を 1.84.0 以降へ更新する。 これで CVE-2026-59822 と CVE-2026-42271 の両方が解消される
- ✓すぐに更新できない場合は、MCPのルートを無効化するか、リバースプロキシ／APIゲートウェイで `/mcp/` と関連するMCPエンドポイントへのアクセスを遮断する。 これは開発元がアドバイザリに明記している回避策
- ✓Starlette を 1.0.1 以降へ更新する。 影響を受けるのは 1.0.0 以下
- ✓FastAPI など Starlette を内部で使うフレームワークを使っている場合も確認する。 直接インストールした覚えがなくても依存として入っている
- ✓`request.url` や `request.url.path` を見て権限判定しているミドルウェアが自分のコードに無いか確認する。あるなら、生の `scope` のパスを見るように直す
- ✓LiteLLM をインターネットに公開している場合、公開の必要性そのものを見直す
上の3つは、いずれもNIST（NVD）がPrimaryとして付けた CVSS v3.1 の値で統一しています。 同じ物差しで並べるためです。GitHubのアドバイザリは一部を CVSS v4.0 で評価しており、数字が違います。
- ▸CVE-2026-59822：NIST の v3.1 で 8.2 / HIGH、GitHub の v4.0 で 8.8 / HIGH
- ▸CVE-2026-42271：NIST の v3.1 で 8.8 / HIGH、GitHub の v4.0 で 8.7 / HIGH
- ▸CVE-2026-48710：NIST・GitHub とも v3.1 で 6.5 / MEDIUM
版が違えば数字も変わるので、NVDを開いて別の数字が出ても混乱しないでください。そして今回は、スコアの大小に意味がありません。 3件とも「実際に悪用されている」側に分類されています。
CVSS 6.5 の脆弱性が「悪用確認済み」に載った
今回いちばん学びがあるのはここです。Starlette の CVE-2026-48710 は 6.5 / MEDIUM で、社内の優先度づけでは後回しにされやすいスコア帯です。
それでも KEV に載りました。KEVは「実際に悪用された証拠がある」脆弱性を載せるカタログです。 スコアが中程度であることと、攻撃に使われるかどうかは別の話だ、という事実がここに出ています。
なお単体でも「情報が少し漏れる」程度の話ではありません。開発元の説明では、`request.url.path` に依存した認可チェックそのものを回避できるため、本来入れないはずの領域の処理が実行されます。
3件それぞれが何をする脆弱性なのかを並べます。
- ▸CVE-2026-59822（LiteLLM・未認証）：偽の `Authorization` ヘッダを送ると、OAuth2パススルーのフォールバック経路が、失敗したはずのキー検証を空の `UserAPIKeyAuth()` で置き換えてしまう。有効なLiteLLMキー無しでMCPツールに到達できる
- ▸CVE-2026-48710（Starlette・認証回避）：`request.url` を見て権限を判定しているミドルウェアを、Hostヘッダの細工ですり抜けられる。パスベースの認可を無効化する
- ▸CVE-2026-42271（LiteLLM・コード実行）：MCPサーバのプレビュー用エンドポイントが、`command` / `args` / `env` を含む設定をそのまま受け取り、プロキシのホスト上でそのコマンドを子プロセスとして起動する。しかも有効なプロキシAPIキーがあるだけで通り、権限チェックが無い
CISAはKEVの記載で、CVE-2026-48710 が CVE-2026-42271 と連鎖しうると明記しています。 48710でパスベースの認可を回避し、42271でホスト上のコマンド実行へ到達する、という組み合わせです。
一方、CVE-2026-59822 については、CISAも開発元のアドバイザリも42271との連鎖には触れていません。 59822で得られるのは「有効なLiteLLMキー無しでMCPツールを列挙・実行できる」ことであり、42271が要求するプロキシAPIキーが手に入るとは書かれていません。本記事では、裏の取れない連鎖を仮定しません。
CVE-2026-42271 は、2026年6月8日の時点ですでにKEVに載っています。 3件はいずれも独立に「悪用されている」と分類されており、どれか1つを直せば済むという関係ではありません。
Starlette の中身：Hostヘッダで request.url.path がずれる
開発元のアドバイザリが挙げている例がそのまま分かりやすいので、仕組みを説明します。
影響を受けるバージョンは、URLを `http://{host}{path}` の形で文字列連結してから再パースしていました。ところが `Host` ヘッダの値は、RFC 9112 §3.2 / RFC 3986 §3.2.2 の文法上、本来 `uri-host [ ":" port ]` しか入りません。そこに `/` `?` `#` のような文字が混ざると、再パースの際にパスやクエリの境界がずれます。
GET /foo HTTP/1.1
Host: example.com/abc?bar=
# 再構築されるURL: http://example.com/abc?bar=/foo
# request.url.path は /abc になる
# ただしルーティングは本物のパス /foo で処理されるルーターは実際のパス `/foo` にディスパッチしてエンドポイントを実行するのに、`request.url.path` を読むミドルウェアには `/abc` に見えます。 「`/admin` 以下は管理者だけ」といったパスベースの認可をミドルウェアで実装していると、そこがすり抜けられます。
1.0.1 では、URLを組み立てる際に `Host` ヘッダを上記RFCの文法に照らして検証するよう修正されました。
この脆弱性が怖いのは、影響範囲が「Starletteを使っている自覚があるかどうか」と無関係な点です。 FastAPI をはじめ、Starlette を土台にしたフレームワークは多く、依存関係の奥に入っています。LiteLLM 自身もその一つです。
自分が影響を受けるか確認する
# インストールされているバージョンを確認する
pip show starlette litellm
# 依存の木のどこから入っているかを確認する
pip install pipdeptree
pipdeptree --reverse --packages starlette
# 更新する
pip install --upgrade 'starlette>=1.0.1'
pip install --upgrade 'litellm>=1.84.0'- ▸Starlette：`1.0.0` 以下が影響を受け、`1.0.1` で修正
- ▸LiteLLM（CVE-2026-59822）：`1.84.0` より前が影響を受け、`1.84.0` で修正
- ▸LiteLLM（CVE-2026-42271）：`1.74.2` 以上 `1.83.7` 未満が影響を受ける。`1.84.0` へ上げれば両方カバーできる
なお、CISAが定めた対応期限は、9月2日に追加された2件が2026年9月16日、6月に追加された CVE-2026-42271 は2026年6月22日でした。これは米国の連邦政府機関に課される期限であって日本の民間企業への強制ではありませんが、「いつまでに直すべきか」の目安としては十分に使えます。
この件から持ち帰れること
CVSSスコアだけで優先度を決めると、今回のような連鎖を取りこぼします。 6.5という数字は「後回しでよい」という意味ではありませんでした。CISAが見ているのは点数ではなく実際に悪用されているかどうかです。スコアで足切りしている運用なら、KEVに載ったかどうかを別軸で見る運用を足してください。
そして、認証を「フレームワークが見てくれている」と思わないことです。 今回のStarletteの件は、`request.url` という一見信頼できそうな値が、外部から送られたヘッダで書き換わるという話でした。権限判定に使う値が、どこまで外部の入力に由来しているのかを一度たどってみる価値があります。
最後に、AI関連の基盤も普通の攻撃対象です。 LiteLLMのようなAIゲートウェイは新しい部品ですが、実体はPythonのWebアプリケーションで、認証の穴もコマンド実行の穴も従来どおり発生します。「AIまわりだから」と別枠で扱わず、他のインターネット公開サーバーと同じ棚卸しに含めてください。