この記事の要点
- LiteLLMのMCP認証にCVE-2026-59822、CVSS 8.8の脆弱性が公表され、偽造トークンでセッションを確立できる問題です。
- 対象は1.84.0未満で、1.84.0以上が修正版とされ、更新できない場合のアクセス制限は暫定策として案内されています。
- CISAのKEVにも2026年9月2日に既知の悪用として追加され、社内や委託先の利用箇所と構成の確認が判断材料です。
公開アドバイザリとCISAの記録をもとに、LiteLLMの認証問題を紹介します。影響を受ける版と、修正版・暫定対策の違いを整理します。
何が起きたのか
今回問題になったのは、BerriAI社が公開したセキュリティアドバイザリ(GHSA-7488-6r32-c95q)です。対象はLiteLLMのMCP Streamable HTTPエンドポイント。認証されていない攻撃者が偽造したBearerトークン(APIアクセス時に使う認証用の文字列)を送るだけで、認証済みセッションを確立できてしまう問題でした。CVE-2026-59822が割り当てられ、深刻度はCVSS 8.8(高)です。
CISAの公式KEVデータでも2026年9月2日に追加され、対応期限は9月16日と記録されています(9月21日確認)。既知の悪用が確認された脆弱性として、優先対応の判断材料になります。
脆弱性の中身をやさしく解説
LiteLLMは、OpenAI形式のAPIでさまざまなLLMを呼び出せる、いわば「AIモデルへの共通の窓口」です。企業が複数のAIモデルやツールをまとめて管理する際によく使われています。
今回の問題はこの窓口の認証まわりで起きていました。LiteLLMにはOAuth2認証をそのまま通過させる「パススルー」機能がありますが、キーの検証に失敗したときのフォールバック処理に穴がありました。本来エラーになるはずの場面で空の認証情報オブジェクト(UserAPIKeyAuth())に置き換わり、正規のキーがないリクエストでもMCPツールの一覧取得・実行まで到達できてしまう仕組みです。鍵をかけ忘れたのではなく、「鍵が壊れているときに鍵なしで通してしまう」設計の抜け穴だったとイメージすると分かりやすいかもしれません。
影響するバージョンと修正・暫定対策
対象はLiteLLM 1.84.0未満、1.84.0以上で修正済みのため、まずバージョンを確認するとよいでしょう。すぐ上げられない場合は、APIゲートウェイ側で/mcp/関連エンドポイントへのアクセスを制限する応急処置も案内されていますが、あくまで暫定策です。直接使っていなくても、社内のAIエージェント基盤やSaaSが内部で利用しているケースもあるため、利用箇所の一覧を基に影響範囲を確認する方法が考えられます。
まとめ:MCP連携がある企業ほど他人事ではない
LiteLLMを運用する方には、稼働版とMCP接続部分の確認が必要な問題です。委託先を含む利用の有無を把握し、公式の修正情報に沿って対応範囲を判断するとよいでしょう。暫定的なアクセス制限と修正版の適用は別の対応として記録できます。
※ 本記事は2026年9月時点の情報にもとづきます。LiteLLMは開発が活発なため、最新の対応状況は公式アドバイザリを確認するとよいでしょう。
