LiteLLM の MCP エンドポイントで認証が素通りする、偽の Authorization ヘッダで未認証のまま MCP ツールへ到達（1.84.0 で修正・KEV 収載）

High（CVSS 8.2）に分類されるBerriAI LiteLLM（OpenAI 互換の形式で各種 LLM API を呼び出すためのプロキシサーバ／AI ゲートウェイ）。NVD の適用範囲は 1.84.0 より前のすべてで、1.84.0 で修正されている。の脆弱性です。LiteLLM の MCP Streamable HTTP エンドポイントで、未認証の攻撃者が認証を回避できる。NVD の記述はこうである。「LiteLLM は OpenAI（またはネイティブ）形式で LLM API を呼び出すためのプロキシサーバ（AI ゲートウェイ）である。1.84.0 より前では、LiteLLM の MCP Streamable HTTP エンドポイントにおいて、未認証の攻撃者が捏造した Authorization ヘッダを使うことで OAuth2 のパススルー・フォールバック経路を発動させることができた。この経路は、失敗した LiteLLM キーの検証を空の UserAPIKeyAuth() オブジェクトで置き換えるため、有効な LiteLLM キーが無いままリクエストが MCP のツール群へ到達しうる。この問題はバージョン 1.84.0 で修正されている」。 **壊れているのは「失敗の扱い方」である。**キー検証そのものは動いている。問題は、検証が失敗したときにアクセスを拒否せず、OAuth2 のパススルーというもう一本の経路へ落ちる作りになっていた点にある。しかもその落ちた先で作られるのが**中身の空の UserAPIKeyAuth() オブジェクト**である。空のオブジェクトは「誰でもない利用者」だが、後続の処理から見れば認証済みの構造体が渡ってきたのと区別がつかない。**認証の失敗が、認証の成功と同じ形をした値に化けている**。これがこの欠陥の本体である。 **必要なのは「それらしい Authorization ヘッダ」だけである。**CVSS 3.1 のベクタは AV:N / AC:L / PR:N / UI:N で、ネットワークから、低い複雑さで、権限も利用者の操作も無しに成立する。有効なキーは要らない。捏造したヘッダを付けて MCP エンドポイントを叩けばよい。 **到達先が MCP のツール群であることを軽く見ないこと。**MCP（Model Context Protocol）は、モデルに外部の道具を渡すための仕組みである。LiteLLM に MCP を繋いでいる構成では、その先に社内 API・データベース・ファイル・チケットシステムといった実際の資源がぶら下がっている。**LLM ゲートウェイの認証をすり抜けるということは、そこに登録された道具を無認証で呼べるということ**である。影響の大きさは LiteLLM 自体ではなく、各組織が MCP に何を繋いだかで決まる。 **指標の版が2つある点に注意する。**GitHub セキュリティアドバイザリ（GHSA-7488-6r32-c95q）は CVSS 4.0 で 8.8（High）、NVD は CVSS 3.1 で 8.2（High）を付けている。**版の違う数字を並べて比較しないこと。**本サイトは CVSS 3.1 の 8.2 を採る。 **CISA KEV に 2026-09-02 付で収載された。**是正期限は 2026-09-16 である。KEV への収載は「実際に悪用が確認された」という意味であり、机上の脆弱性ではない。

対応は **LiteLLM を 1.84.0 以上へ更新する**ことである。回避設定ではなく版を上げる。 **まず自分のところが対象かを確定させる。**pip で入れているなら `pip show litellm`、コンテナなら実行中イメージのタグを見る。**1.84.0 より前はすべて対象**なので、版が読み取れない状態（`latest` タグの運用など）は「対象でない」ではなく「確認できていない」として扱う。 **MCP を使っていない構成でも、まず更新する。**この欠陥の成立条件は MCP Streamable HTTP エンドポイントが叩けることである。MCP を使っていなければ実害は限定されるが、**エンドポイントが無効化されている確証が無いなら、使っていないという自己申告を根拠にしない**。更新のほうが速くて確実である。 **更新までの時間を稼ぐなら、経路を閉じる。**LiteLLM のプロキシをインターネットへ直接出している構成が最も危ない。VPN の内側へ入れる、ロードバランサやリバースプロキシで MCP のパスを外から遮断する、IP 制限を掛ける。いずれも修正ではないが、AV:N という前提条件を1段崩せる。 **更新後は「既に踏まれていなかったか」を見る。**確認する順序は3つある。①LiteLLM のアクセスログで、MCP エンドポイントに対して**キー検証に失敗した直後に成功として処理されたリクエスト**が無いか。②MCP に登録した各ツールの側のログで、LiteLLM 経由の身に覚えのない呼び出しが無いか。③LiteLLM に保管している上流プロバイダの API キー（OpenAI・Anthropic 等）に、想定外の使用量や課金が出ていないか。**ゲートウェイが抜かれた場合、被害はゲートウェイの外側に出る。**疑いがあるなら上流のキーは再発行する。

BerriAI LiteLLM（OpenAI 互換の形式で各種 LLM API を呼び出すためのプロキシサーバ／AI ゲートウェイ）。NVD の適用範囲は 1.84.0 より前のすべてで、1.84.0 で修正されている。 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-59822）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。

はい。CISA の既知の悪用された脆弱性カタログ（KEV）に登録されており、実環境での悪用が確認されています。米国連邦機関向けの対応期限の目安は 2026/09/16 です。早急な対応が推奨されます。