LLM Frontline
ニュース・動向

LiteLLMのMCPゲートウェイに任意コマンド実行の脆弱性(CVE-2026-42271)｜業務目線で読む

イツキ・編集長 / ニュース・動向担当
・ 約9分で読めます
LiteLLMのMCPゲートウェイに任意コマンド実行の脆弱性(CVE-2026-42271)｜業務目線で読む

複数のLLMプロバイダやMCPサーバーを一本化して社内に提供する「AIゲートウェイ」は、運用の窓口を一つにまとめられる分、ゲートウェイ自体が破られたときの影響範囲も大きくなります。OSSのLLM/AIゲートウェイであるLiteLLM(BerriAI/litellm)で、MCPサーバーの接続テスト機能に任意コマンド実行の脆弱性CVE-2026-42271が見つかり、CISAのKnown Exploited Vulnerabilities(KEV)カタログにも追加されました。この記事では、何が起きたのか、MCPという規格自体の欠陥ではなく実装の不備だったという点、そして実務でいま何をすべきかを整理します。

何が起きたか:プレビュー用エンドポイントがコマンド実行を許してしまった

LiteLLM Proxyには、MCPサーバーを登録する前に接続を試せる、いわばプレビュー機能があります。具体的にはPOST /mcp-rest/test/connectionとPOST /mcp-rest/test/tools/listという2つのエンドポイントで、MCPサーバーの設定(command・args・env)をリクエストボディでそのまま受け取り、保存する前に接続テストを行う作りになっていました。

問題は、stdioトランスポート(ローカルプロセスとして起動するMCPサーバーの接続方式)の設定を渡された場合に、このテスト処理がそのcommandをLiteLLM proxyのホスト上でサブプロセスとして実際に起動してしまっていたことです。GitHubのセキュリティアドバイザリ(GHSA-v4p8-mg3p-g94g)によれば、保存用のエンドポイントと同じくPROXY_ADMINロールが必須のはずが、このテスト用の2エンドポイントには権限チェックが実装されておらず、有効なプロキシAPIキーさえあれば誰でも到達できる状態でした。つまり、社内で発行された低権限の内部ユーザー用キーを持っているだけで、プロキシのホスト上で任意のコマンドを実行できてしまう状態だったことになります。

注意

この脆弱性は「MCPという規格に欠陥があった」わけではありません。MCPサーバーをどう安全にテストさせるかという、LiteLLM側の実装(権限チェックの実装漏れ)が原因です。MCP自体の基本的な考え方については

あわせて読みたい

MCP(Model Context Protocol)とは何か｜AIと社内システムをつなぐ標準と業務での使いどころ

で整理していますので、規格の理解と実装リスクの理解は分けて捉えてください。

影響範囲と修正状況

GitHubのアドバイザリによると、影響を受けるのはLiteLLM 1.74.2以上1.83.7未満です。CVSSスコアはv3.1で8.8、v4.0で8.7とHigh(高)に区分されています。修正版の1.83.7では、両エンドポイントにPROXY_ADMINロールのチェックが追加され、保存用エンドポイントと同じ権限要件に揃えられました。LiteLLMのリリースノートでも、この修正が「stdioトランスポート経由の任意コマンド実行をブロックする」対応として記載されています。

CISAは2026年6月8日付でCVE-2026-42271をKEV(Known Exploited Vulnerabilities)カタログに追加しました。KEVは実際に悪用が確認された脆弱性を米国政府機関向けに一覧化するもので、連邦機関に対する対応期限は同年6月22日に設定されています。KEV掲載は、単なる理論上のリスクではなく実際の悪用が観測された脆弱性であることを示すシグナルであり、民間企業においても優先度を上げてパッチ適用を検討する材料になります。

より深刻なのは別脆弱性との連鎖

このCVE-2026-42271は、単体でも「認証済みユーザーによる任意コマンド実行」として深刻ですが、セキュリティ各社が指摘しているのは、Starlette(LiteLLMが依存するASGIフレームワーク)の別の脆弱性CVE-2026-48710(通称BadHost)と組み合わさった場合のリスクです。

CVE-2026-48710は、HTTPのHostヘッダーが検証されないままrequest.urlの再構築に使われることで、パスベースのセキュリティ判定を細工したHostヘッダーで迂回できてしまう脆弱性です。Horizon3.aiなどの分析によれば、この2つを組み合わせると、有効なAPIキーを持たない攻撃者でも認証チェックを迂回したうえでコマンド実行に到達できる、いわゆる「認証なしのリモートコード実行(unauthenticated RCE)」に発展しうるとされています。

メモ

CVE-2026-48710(Starlette)は1.0.1で修正されています。LiteLLM単体のパッチだけでなく、依存しているStarletteのバージョンも合わせて確認する必要があります。

実務でやるべきこと

  1. 1

    バージョン確認

    運用中のLiteLLM Proxyのバージョンを確認します。1.74.2以上1.83.7未満に該当する場合は対象です。あわせてStarletteの依存バージョンが1.0.1未満かどうかも確認してください。
  2. 2

    アップグレード

    1.83.7以降へアップグレードします。Starletteも1.0.1以降に更新されているか確認します。バージョン更新の詳細はLiteLLMの公式リリースノートを参照してください。
  3. 3

    即時アップグレードが難しい場合の暫定遮断

    すぐに更新できない場合は、リバースプロキシやAPIゲートウェイの側でPOST /mcp-rest/test/connectionとPOST /mcp-rest/test/tools/listへのアクセスを遮断します。これはGitHubアドバイザリでも回避策として明記されている方法です。
  4. 4

    ロールベースアクセス制御の総点検

    今回の根本原因は「保存用と同等の危険な操作のはずが、権限チェックが1系統だけ漏れていた」ことです。自社でLiteLLMや他のAIゲートウェイを運用している場合、テスト用・プレビュー用など「本番操作の下位互換に見える機能」にも同じ権限要件が及んでいるか、あらためて洗い出す価値があります。

対応チェックリスト

  • LiteLLM Proxyのバージョンを確認した(1.74.2以上1.83.7未満に該当するか)
  • Starletteの依存バージョンを確認した(1.0.1未満かどうか)
  • 1.83.7以降・Starlette 1.0.1以降へアップグレードした、または暫定遮断を実施した
  • MCPテスト用エンドポイントへのアクセスログを確認し、不審なcommand/args/env指定がないか点検した
  • プロキシAPIキーの発行範囲・ロール設計を棚卸しした

MCPを安全に使うために

MCP経由でツールやシステムをAIエージェントにつなぐ構成は、社内導入が広がっている一方で、外部のコマンドやプロセスを扱う性質上、権限設計を誤ると影響が大きくなりやすい領域です。MCPそのものの基本設計は

あわせて読みたい

MCP(Model Context Protocol)とは何か｜AIと社内システムをつなぐ標準と業務での使いどころ

で解説していますが、今回のようにゲートウェイ側の実装不備がMCPの機能と組み合わさることで、想定外の実行権限を攻撃者に渡してしまうケースは今後も起こり得ます。ガードレールや権限設計の考え方は

あわせて読みたい

LLMガードレールの設計｜入力・出力・挙動の3層で安全境界をつくる実務ガイド

も参考にしてください。

MCPサーバーの登録画面に「テスト接続」ボタンがあることは知っていましたが、それが裏でコマンドを実際に実行しているとは意識していませんでした。プレビュー機能だからといって権限を軽く見ないよう、社内のレビュー観点に追加しました。
LiteLLMでゲートウェイを運用するSRE

脆弱性の詳細・影響バージョン・修正内容はGitHubセキュリティアドバイザリ(GHSA-v4p8-mg3p-g94g)、KEV掲載日はCISA公式カタログを一次情報として確認しています。CVE-2026-48710との連鎖に関する分析はHorizon3.aiおよびCloud Security Allianceの報告に基づきます。攻撃の実際の悪用状況・手口の詳細は本記事執筆時点で全容が明らかになっていない部分があり、断定を避けています。

自社ではMCP機能を使っていませんが、影響はありますか。
今回の脆弱性はMCPサーバーのテスト用エンドポイントに存在するものなので、MCP機能を有効化・利用していないLiteLLM Proxyであれば直接の攻撃経路にはなりにくいと考えられます。ただし該当バージョンを使っている場合は、念のためアップグレードしておくことをおすすめします。エンドポイント自体が有効かどうかは自社の設定を確認してください。
パッチを当てれば、この件はもう心配しなくていいですか。
1.83.7以降へのアップグレードとStarletteの更新で今回の脆弱性そのものには対応できます。ただし今回明らかになったのは『テスト用エンドポイントの権限チェック漏れ』という個別の不備なので、他の管理系エンドポイントについても権限設計を点検しておくと安心です。
MCP自体を使うのをやめたほうがいいのでしょうか。
今回の問題はMCPという規格の欠陥ではなく、LiteLLM側の実装の不備です。MCPサーバーとの連携を今後も使う前提で、ゲートウェイやプロキシ側の権限設計・監査ログ・パッチ適用体制を整えるほうが現実的な対応です。

出典・参考

この記事をシェア

関連する記事

開発・エージェント

MCP(Model Context Protocol)とは何か｜AIと社内システムをつなぐ標準と業務での使いどころ

MCP(Model Context Protocol)は、AIと社内システムやツールをつなぐための共通規格です。連携のNxM問題をどう解くのか、ホスト・クライアント・サーバーという基本構成、既製サーバーを選んで繋ぐ導入の仕方、そして権限や監査ログといった業務導入時の注意点を、冷静に整理します。

開発・エージェント

LLMガードレールの設計｜入力・出力・挙動の3層で安全境界をつくる実務ガイド

LLMを組み込むアプリ・エージェントに欠かせないガードレール設計を、実装アーキテクチャの目線で整理します。システムプロンプトだけでは安全境界にならない理由、入力・出力・挙動の3層構成、分類器やスキーマ検証・OSSフレームワークといった実装手段の類型、過剰検知と過小防御のトレードオフ、評価とレッドチーミングの必要性までを扱います。