LiteLLMの脆弱性CVE-2026-42271の悪用
- タグ
- 国外
LiteLLMでMCPサーバーを保存前に試す2つのエンドポイントはロールを確かめず、有効なプロキシのAPIキーを持つ利用者ならホストで任意のコマンドを実行できた（CVE-2026-42271）［4］。CISAは、この脆弱性を既知の悪用された脆弱性（KEV）のカタログに加えた［4、5］。その後、Wiz、Microsoft、CounterCraftがLiteLLMを狙った攻撃の観測を報告した［11、12、13］。
脆弱性の内容
LiteLLMの文書では、LiteLLMは100以上のLLMをOpenAIの形式の単一のインターフェースで呼べるオープンソースのライブラリで、仮想キー・費用の追跡・管理UIを備えたセルフホストのLLM Gateway（Proxy）を持つ［7］。開発元のBerrie AI Incorporatedは、2023年に創業したサンフランシスコの会社である［9］。
CVE Programの2026年5月8日の記録では、POST /mcp-rest/test/connectionとPOST /mcp-rest/test/tools/listの2つのエンドポイントが、stdioトランスポートで使うcommand・args・envを含むサーバーの設定全体をリクエストの本文で受け付けた［4］。stdioの設定で呼ばれると接続を試み、与えられたコマンドをプロキシのホストで、プロキシのプロセスの権限の子プロセスとして起動した［4］。低い権限の内部利用者のキーを持つ者も、この方法でコマンドを実行できた［4］。
| 項目 | 値 | 資料 |
|---|---|---|
| CVE | CVE-2026-42271（勧告GHSA-v4p8-mg3p-g94g、CNAはGitHub_M） | ［4］ |
| CVSS（CNA） | 8.7（v4.0、HIGH） | ［4］ |
| CVSS（Red Hat） | 8.8（v3.1、Important） | ［3］ |
| CWE | CWE-77（コマンドインジェクション）、CWE-78（OSコマンドインジェクション） | ［4］ |
| CISAのSSVCの評価 | Exploitationがactive、Automatableがno、Technical Impactがtotal | ［4］ |
LiteLLMは4月21日の告知で、stdioのMCPサーバーを追加するとcommandの値がそのままStdioServerParametersに渡り、プロキシのホストで子プロセスとして実行されたと説明した〔注1〕［1］。影響を受ける面には、MCPサーバーの作成・更新、2つのテスト用エンドポイント、実行時に設定かDBから再構成されるサーバーを挙げた［1］。テスト用エンドポイントは、何も保存せずにコマンドを実行させる最も容易な経路だったとした［1］。LiteLLMは、認証されていない利用者には悪用できなかったと説明し、開示者としてOX Securityの研究チームを挙げた［1］。
Starletteの脆弱性との連鎖
LiteLLMの6月1日の告知では、プロキシのHostヘッダーによる認証回避（GHSA-4xpc-pv4p-pm3w、CVE-2026-48710）に対処した更新はv1.84.0で出た［8］。細工したHostヘッダーで認証のゲートが実際に応答するルートと異なるルートを評価し、保護された管理用ルートに認証なしでアクセスされるおそれがあった［8］。原因は、StarletteがHostヘッダーから組み立てるrequest.url.pathからルートを導いていたことだった［8］。
LiteLLMは、影響を受けるのはv1.84.0より前の版でプロキシサーバーを動かし、そのリスナーに信頼できないクライアントが届く場合（Python SDKだけの利用は含まない）だとした［8］。LiteLLM Cloudの顧客には影響がなかったと説明した［8］。
Horizon3.aiの報告によると、同社の研究者は、CVE-2026-42271をCVE-2026-48710（BadHost）と連鎖させると認証の要件を完全に回避できることを確かめた［10］。回避が成り立つのは依存関係にStarlette 1.0.0以下を含むLiteLLMの展開で、認証情報なしのリモートコード実行になるとした［10］。Horizon3.aiは連鎖の深刻度をCVSS 10.0（Critical）と評価した［10］。CVE-2026-48710単体のCVSSを、The Hacker Newsは6.5と伝えた［15］。
The Hacker Newsは9月3日の記事で、CISAがCVE-2026-48710を含む7件をKEVに加えたと報じた［16］。StarletteとLiteLLMの脆弱性への対応期限は9月16日だった［16］。
時系列
| 日付 | 主体 | 内容 | 資料 |
|---|---|---|---|
| 2026年 | OX Security | AnthropicのMCP SDKのstdioトランスポートのコマンドインジェクションを扱う勧告を公表した | ［1］ |
| 2026年 | LiteLLM | v1.83.7-stableを公開し、リリースノートにMCP stdioトランスポートによる任意のコマンド実行を防ぐ変更（PR #25343）を載せた | ［2］ |
| 2026年 | LiteLLM | MCP stdioのコマンドインジェクションの修正を告知した | ［1］ |
| 2026年 | CVE Program | CVE-2026-42271を公開した | ［4］ |
| 2026年 | LiteLLM | Hostヘッダーによる認証回避CVE-2026-48710に対処した更新を告知した | ［8］ |
| 2026年 | Horizon3.ai | CVE-2026-48710との連鎖で認証なしのリモートコード実行になることを確かめたと発表した | ［10］ |
| 2026年 | CISA | CVE-2026-42271をKEVに加え、対応期限を2026年6月22日とした | ［5］ |
| 2026年 | Red Hat | OpenShift AI 3.4・2.25・3.3の修正を出した | ［3］ |
| 2026年 | Microsoft | LiteLLMゲートウェイを起点とする攻撃者の活動の観測を公表した | ［12］ |
| 2026年 | Wiz | ハニーポットでのLiteLLMへの悪用の観測を公表した | ［11］ |
| 2026年 | CounterCraft | 囮のホストでの悪用と、攻撃者による許可リストの改変の記録を公表した | ［13］ |
対象の製品と版
CVE記録では、影響を受けるのはlitellmの1.74.2以上1.83.7未満の版である［4］。LiteLLMは告知で、修正はv1.83.6-nightly以降のすべてのリリースに入り、v1.83.7-stableが修正を含む最初の安定版だと説明した［1］。
Red Hatは、この脆弱性をAnsible Automation PlatformやOpenShift AIなどの同社製品に組み込まれたLiteLLMに影響する、深刻度Importantの欠陥と説明した［3］。
| 製品 | 状態 | 修正版・アドバイザリ | 資料 |
|---|---|---|---|
| Red Hat OpenShift AI 3.4（rhoai/odh-trustyai-garak-lls-provider-dsp-rhel9） | 修正版あり | RHSA-2026:27784 | ［3］ |
| Red Hat OpenShift AI 2.25（rhoai/odh-llama-stack-core-rhel9） | 修正版あり | RHSA-2026:28960 | ［3］ |
| Red Hat OpenShift AI 3.3（rhoai/odh-llama-stack-core-rhel9） | 修正版あり | RHSA-2026:30056 | ［3］ |
| Ansible Automation Platform 2（lightspeed-chatbot-rhel9の2件） | 影響なし（Not affected） | - | ［3］ |
| Exploit Intelligence | 影響なし（Not affected） | - | ［3］ |
| Red Hat OpenShift AI（odh-mlflow-rhel9） | 影響なし（Not affected） | - | ［3］ |
悪用の状況
NVDに載った米サイバーセキュリティ・インフラストラクチャ安全保障庁（CISA）の項目によると、KEVが求める対応は、ベンダーの指示に従う緩和策の適用、クラウドサービスではBOD 22-01の指針に従うこと、緩和策が無ければ製品の使用の中止である［5］。
Help Net Securityは6月9日の記事で、CVE-2026-42271が使われた攻撃の詳細は出ておらず、攻撃者が同時にCVE-2026-48710を悪用している確認もないと報じた［14］。
Wizの8月27日の報告では、同社のハニーポットで、LiteLLMに対するMCP関連の2種類の脆弱性（MCPゲートウェイの認証回避と、MCPサーバーのテスト用エンドポイントのコマンドインジェクション）の悪用を観測した［11］。攻撃者は偽のMCP stdioサーバーの設定を送り、commandにクリプトマイナーをダウンロードして実行するPythonスクリプトを入れた［11］。そのうえで正しいMCPのハンドシェイクを返し、接続テストを成功したように見せた［11］。マイナーはメモリ上で動き続け、ディスクには調べる手がかりがほとんど残らないとWizは書いた［11］。
Wizは、外部の研究者がQilinランサムウェアのグループをこの連鎖の悪用と結び付けたとも書いた〔注2〕［11］。
Microsoftの報告によると、LiteLLMゲートウェイの文脈で観測した攻撃者の活動は、Pythonのドロッパー、実行時の秘密情報の収集、PostgreSQLの収集、マイナーの展開、永続化だった［12］。初期侵入は露出したLiteLLMゲートウェイの悪用による可能性が高く、CVE-2026-42271とCVE-2026-48710の連鎖と整合するとMicrosoftは評価した［12］。攻撃者は収集したデータベースの接続文字列で、Azure Database for PostgreSQL上のLiteLLMのデータ層に入った［12］。
CounterCraftの10月21日の報告では、1日目に攻撃者が、CVE-2026-42271に脆弱なLiteLLMプロキシを動かす囮（deception）のホストを悪用した［13］。テスト接続のエンドポイントは許可リストにあるstdioのコマンドを起動し、python3が許可リストにあった［13］。攻撃者は自前のMCPサーバーを登録してLiteLLMのtools/callのAPIでホストを操作し、環境と設定ファイルからLLMの提供元のキーとデータベースの設定を集めた［13］。
CounterCraftは、攻撃者がLiteLLMのconstants.pyにstdioの許可リストを空にする2行を足したと書いた［13］。この変更の2分後に別の攻撃者が同じエクスプロイトを送り、422の応答を2回受けた［13］。
| 種別 | 値 | 示した組織 | 資料 |
|---|---|---|---|
| 登録されたMCPサーバーの名前 | wv8pwn | CounterCraft | ［13］ |
| constants.pyに足された注釈 | # security hotfix 2026-10-11: stdio MCP transport commands disabled (CVE-2026-42271) | CounterCraft | ［13］ |
| authorized_keysへの追記 | rootとサービスアカウントのauthorized_keysに加えたSSHの認証局の行 | CounterCraft | ［13］ |
| 永続化の痕跡 | サービスアカウントのauthorized_keysへの書き込み | Microsoft | ［12］ |
| 狙われたテーブル | LiteLLM_ProxyModelTable、LiteLLM_VerificationToken | Microsoft | ［12］ |
修正と回避策
LiteLLMは4月21日の告知で、PR #25343（commit 7b7f304）の修正の中身を挙げた［1］。
- stdioのcommandを既知のMCPの起動コマンド（npx、uvx、python、python3、node、docker、deno）に限る許可リストMCP_STDIO_ALLOWED_COMMANDSを設け、環境変数LITELLM_MCP_STDIO_EXTRA_COMMANDSで追加できるようにした［1］。
- NewMCPServerRequestとUpdateMCPServerRequestが、許可リストに無いcommandの設定を受け付けないようにした［1］。
- stdioのクライアントを作るときにもcommandを再検証し、許可リストより前のDBの行や設定から再構成したサーバーも起動時に止めるようにした［1］。
- 2つのテスト用エンドポイントに、PROXY_ADMINのロールを求めるようにした［1］。
同じ告知によると、利用者への推奨は3つあった［1］。
- v1.83.7-stable以降に更新する（nightlyではv1.83.6-nightly以上が修正済み）［1］。
- 既存のstdioのMCPサーバーを点検する（許可リストに無いcommandの行は起動に失敗する）［1］。
- PROXY_ADMINを持つ者を見直す（管理者以外にMCPのテストを任せていた場合、その利用者は403を受ける）［1］。
Horizon3.aiは、LiteLLMを1.83.7以降に、Starletteを1.0.1以降に更新するよう勧めた〔注3〕［10］。すぐに更新できない場合は、テスト用エンドポイントへのアクセスの遮断、信頼できるセグメントへのネットワークの制限、プロキシが保持する認証情報の入れ替え、ログの確認を挙げた［10］。
LiteLLMのMCP Gatewayの文書では、stdioのMCPサーバーは既定で無効で、プロキシをLITELLM_ENABLE_MCP_STDIO=trueの環境で起動したときだけ有効になる［6］。無効の間はUIでstdioを選べず、stdioのサーバーの作成・更新はエラーを返し、既存のstdioのサーバーは起動しない［6］。
未公表の事項
- CISAがKEVに加えた根拠となった悪用の観測
- 悪用の件数と被害を受けた組織
- Qilinランサムウェアとの結び付きの根拠と、それを示した外部の研究者
注
出典
当事者
- ［1］BerriAI『Security Update: CVE-2026-30623 — Command Injection via Anthropic's MCP SDK』（2026年4月21日公開）
- ［2］BerriAI『LiteLLM v1.83.7-stable - Per-User MCP OAuth, Team Spend Logs RBAC』（2026年4月18日公開）
- ［8］BerriAI『Fixed in 1.84.0+ - Version Update: Authentication Bypass via Host Header Injection (GHSA-4xpc-pv4p-pm3w)』（2026年6月1日公開）
関係組織
- ［3］Red Hat, Inc.『CVE-2026-42271』（2026年5月8日公開）
公的機関
- ［4］CVE Program『CVE-2026-42271 LiteLLM: Authenticated command execution via MCP stdio test endpoints』（2026年5月8日公開、2026年7月15日更新）
- ［5］National Institute of Standards and Technology『CVE-2026-42271』（2026年5月8日公開、2026年10月26日更新）
調査・観測
- ［10］Horizon3.ai『CVE-2026-42271 Chained with CVE-2026-48710 — LiteLLM Unauthenticated Remote Code Execution via Starlette Host Header Validation Bypass』（2026年6月1日公開、2026年8月1日更新）
- ［11］Wiz, Inc.『Inside 90 days of attacks on AI infrastructure』（2026年8月27日公開）
- ［12］Microsoft Corporation『When AI infrastructure becomes the target: Securing gateways and control points』（2026年8月26日公開）
- ［13］CounterCraft Security『LiteLLM Hacked Four Ways: An Attacker Patched Just One』（2026年10月21日公開、2026年10月23日更新）
報道機関
- ［14］Help Net Security『LiteLLM vulnerability under active attack, CISA warns (CVE-2026-42271)』（2026年6月9日公開）
- ［15］The Hacker News『LiteLLM Flaw CVE-2026-42271 Exploited in the Wild, Chains to Unauthenticated RCE』（2026年6月9日公開）
- ［16］The Hacker News『CISA Adds Seven Exploited Flaws as Attackers Deploy Reverse Shells and Crypto Miners』（2026年9月3日公開）
背景資料
- ［6］BerriAI『MCP Gateway』（公開日不明、2026年11月4日閲覧）
- ［7］BerriAI『Getting Started』（公開日不明、2026年11月4日閲覧）
- ［9］Berrie AI Incorporated『About LiteLLM』（公開日不明、2026年11月4日閲覧）
更新記録
- 2026年6月9日：公開した。
- 2026年7月15日：CVE Programの記録の7月15日の更新（出典4）に合わせ、「脆弱性の内容」の表を改めた。
- 2026年8月1日：Horizon3.aiの報告の8月1日の更新（出典10）に合わせ、「脆弱性の内容」のStarletteの脆弱性との連鎖の小節と「修正と回避策」を改めた。
- 2026年8月26日：Microsoftの報告（出典12）で示された攻撃者の活動と痕跡を「悪用の状況」と「時系列」に加えた。
- 2026年8月27日：Wizの報告（出典11）で示されたハニーポットでの悪用を「悪用の状況」と「時系列」に加え、Qilinランサムウェアとの結び付きを「未公表の事項」に加えた。
- 2026年9月3日：The Hacker Newsの記事（出典16）が伝えたCVE-2026-48710のKEVへの追加を「脆弱性の内容」に、Qilinランサムウェアについての報道を「注」に加えた。
- 2026年10月21日：CounterCraftの報告（出典13）で示された囮のホストでの悪用と痕跡を「悪用の状況」と「時系列」に加え、リードの最後の文を改めた。
- 2026年10月23日：CounterCraftの報告の10月23日の更新（出典13）に合わせ、「悪用の状況」を改めた。
- 2026年10月26日：NVDの記録の10月26日の更新（出典5）に合わせ、「悪用の状況」のKEVが求める対応を改めた。