メインコンテンツへスキップ
LiteLLM CVE-2026-42271 ─ MCP接続テスト機能のコマンドインジェクションで確認すること
ニュース 中級

LiteLLM CVE-2026-42271 ─ MCP接続テスト機能のコマンドインジェクションで確認すること

ニュース 中級

CISA KEVに追加されたLiteLLM CVE-2026-42271について、MCP接続テスト機能、低権限キー、AI Gatewayの公開範囲、APIキー、ログ、更新判断を防御側の初動として整理する。

何が起きたか

2026年6月8日、CISABerriAI LiteLLM の CVE-2026-42271 を Known Exploited Vulnerabilities(KEV)Catalog に追加した。NVDとGitHub Advisoryでは、LiteLLM の MCP サーバー接続を保存前にテストする機能に関するコマンドインジェクション脆弱性として説明されている。

GitHub Advisory によると、影響範囲は LiteLLM 1.74.2 以上 1.83.7 未満、修正版は 1.83.7 だ。重要なのは、管理者だけでなく、有効な proxy API key を持つ低権限の internal-user キーでも影響し得る点である。つまり、AI Gatewayの「利用者キー」と「管理者権限」を分けているつもりでも、該当バージョンでは境界が崩れる可能性がある。

MCPやLiteLLMの利用有無を先に確認する

この記事では、影響機能の詳細な呼び出し手順や攻撃再現は扱わない。防御側が見るべきなのは、LiteLLMの対象バージョン、MCP接続テスト機能の利用有無、proxy API keyの発行範囲、プロキシホスト上のログと資格情報の影響だ。

影響を受ける可能性がある組織・担当者

LiteLLM は、複数のLLM APIをまとめる AI Gateway / LLMプロキシとして使われることが多い。MCP連携を検証している組織では、プロキシが社内ツール、データベース、開発環境、SaaS APIへ接続する中継点になっている場合がある。

読者・担当まず見るべきこと影響の考え方
AI基盤・SRELiteLLMのバージョン、MCP機能、proxy API key発行範囲プロキシホスト上で意図しない処理が実行された可能性を切り分ける
開発者検証環境、PoC、ローカル以外に公開されたLiteLLM検証用途でも有効なAPIキーや社内接続を持っていれば対象になる
情シス・SaaS管理者LLM APIキー、管理者トークン、接続先SaaSAI Gatewayを経由した不正利用や過剰課金を確認する
SOC・CSIRTプロキシログ、IdPログ、ホスト監査ログ、利用量ログ更新だけでなく、低権限キーの悪用疑いをログで確認する

なぜ重要か

LiteLLMのCVEとしては、すでに CVE-2026-42208 のSQL Injection を扱っている。今回のCVE-2026-42271は、SQL Injectionではなく、MCP接続テスト機能に関係する別の問題だ。

AI Gatewayは、単なるWebアプリよりも資格情報が集中しやすい。LLM APIキー、プロキシDB、利用ログ、モデルルーティング、社内API接続、MCPサーバー設定が同じ運用面に集まるため、侵害時の影響は「LiteLLMだけ」に閉じない。

特に今回のポイントは、低権限キーでも影響し得ることだ。管理者権限だけを見て安心すると、internal-userキー、検証用キー、期限切れのはずのキー、CI/CD用キーを見落とす。

まず確認すべきこと

最初の確認は、攻撃可否の検証ではなく、対象環境とキーの棚卸しだ。

  1. LiteLLM 1.74.2以上1.83.7未満が本番、検証、PoC、開発者向け環境に残っていないか確認する。
  2. MCPサーバー接続テスト機能を有効化・検証・公開していた環境があるか確認する。
  3. proxy API key、internal-user key、管理者キー、CI/CDキーの発行先と最終利用時刻を確認する。
  4. LiteLLMプロキシホスト上のプロセス、監査ログ、アプリケーションログ、IdPログを同じ時間軸で確認する。
  5. LLM APIキー、DB接続情報、Secret Manager、環境変数、プロンプトログの露出可能性を評価する。
  6. 更新、暫定緩和、キー失効、ログ保全、関係者連絡の責任者を決める。

作業には AIプロキシ・LLM APIキー漏えい確認チェックリスト を使う。一般的なCVE優先度の判断は CVE初動対応チェックリスト に分けている。

推奨される初動対応

すぐに行うこと:

  • GitHub Advisory、NVD、CISA KEVで対象バージョン、修正版、Required Actionを確認する
  • LiteLLMを1.83.7以降へ更新し、実際に稼働中のコンテナ・プロセスも更新後であることを確認する
  • すぐに更新できない場合は、公式情報に沿ってMCP接続テスト機能への到達範囲を制限する
  • proxy API keyとinternal-user keyを棚卸しし、不要・広範・期限不明のキーを失効する
  • プロキシホスト、IdP、WAF/API Gateway、利用量・課金ログを保全する

やらないこと:

  • 自社外のLiteLLM環境に対して確認リクエストを送らない
  • PoCや攻撃手順で「再現できるか」を試さない
  • 管理者キーだけをローテーションし、低権限キーやCI/CDキーを見落とさない
  • 更新済みという事実だけで、ログ確認やキー失効判断を省略しない

記録すべきこと:

  • 対象環境、LiteLLMバージョン、MCP機能の利用有無、公開範囲
  • 発行済みproxy API key、internal-user key、管理者キー、失効・再発行結果
  • プロキシホストの監査ログ、LiteLLMログ、IdPログ、利用量ログの確認範囲
  • 不審利用の有無、未確認項目、残リスク、次回確認日

判断基準

優先度条件推奨判断
対象バージョン、外部または広い社内公開、MCP機能利用、低権限キーを多数発行緊急更新、到達範囲制限、キー棚卸し、ログ保全、CSIRT連携を同時に進める
対象バージョンだが社内限定、MCP機能未利用または到達制限あり更新を前倒しし、キーとログの影響確認を行う
対象外バージョン、LiteLLM未利用、またはMCP機能未導入が確認済み対象外根拠を残し、AI Gateway棚卸しに反映する

関連する CyberLens 内部リンク

公式情報・参考情報

まとめ

CVE-2026-42271 は、LiteLLMをAI Gatewayとして使う組織にとって、単なるパッケージ更新では終わらない。MCP連携、proxy API key、internal-user key、プロキシホストの監査ログ、LLM APIキーを同時に見る必要がある。

既にLiteLLM関連のCVEを確認した組織でも、SQL Injectionと同じチェックで完了にしない方がよい。今回の論点は「低権限キーでどこまで操作できたか」と「プロキシホスト側の影響」だ。AIプロキシ・LLM APIキー漏えい確認チェックリスト を更新したので、更新、キー棚卸し、ログ確認、残リスクの記録まで一つの流れで進めたい。

関連テーマを体系的に学ぶ 脆弱性管理(CVE・KEV)対応ガイド
ESC