Hackers Can Turn Vulnerable LiteLLM AI Gateways Into Root Access and Cloud Credential Theft
2026/09/10 gbhackers — インターネットへ公開された LiteLLM AI ゲートウェイの約 10 台に 1 台が、広く知られているデフォルトのマスターキー “sk-1234” を受け入れる状態にあるほか、認証を必要としない状態にもなっている。インターネットで公開された 3,074 件のインスタンスを対象としたスキャンでは、294 システム (9.6%) がデフォルトキーを受け入れ、191 インスタンス (6.2%) では認証が有効化されていなかった。こうした問題により、LLMjacking や機密性の高い認証情報の漏洩が発生し、ゲートウェイ・コンテナ内で root 権限によるコード実行に至るとされる。
外部から到達可能な脆弱性の中で最も深刻な CVE-2026-59822 は、LiteLLM の Model Context Protocol (MCP) Streamable HTTP エンドポイントに影響を及ぼす。LiteLLM のバージョン 1.84.0 未満では、攻撃者が任意の Bearer トークンを与えることで OAuth2 のフォールバック経路を発動させ、API キーの検証失敗を空の認証済みユーザー・オブジェクトへと変換する可能性がある。つまり、わずか 1 文字のトークンであっても、有効な MCP セッションを確立して、正規の LiteLLM キー なしで設定済みの MCP ツールへアクセスする可能性があった。
この問題が極めて深刻なのは、MCP サーバがデータだけでなく、何らかの操作を実行する機能も公開している場合が多いためである。具体的には、侵害されたゲートウェイを通じて、導入環境の構成に応じて内部データベース、ソースコード・リポジトリ、チケット管理システム、Slack ワークスペース、ファイルストア、CI/CD ツールなどの企業向けサービスへのアクセスが可能となる。この脆弱性は、すでに CISA の Known Exploited Vulnerabilities (KEV) カタログにも追加されており、実環境での悪用が確認されている。
2 つ目の脆弱性 CVE-2026-59821 は、LiteLLM の Custom Code Guardrails 機能に影響を及ぼす。本番環境で使用される Guardrail の作成と更新のエンドポイントでは、送信された Python コードに対して UI のテスト用ワークフローで実施されるサンドボックス化と危険なパターンに対する検証が適用されず、対象のコードがコンパイルされ、実行されていた。
LiteLLM AI ゲートウェイ
Wiz の研究者が複数の脆弱性を発見した LiteLLM は、OpenAI／Anthropic／AWS Bedrock／Azure／Google Vertex AI などの LLM プロバイダーへのアクセスを一元管理するために使用されるオープンソースのゲートウェイである。
Guardrail を作成／変更できる特権ユーザーは、LiteLLM のプロキシ環境で Python を実行するため、プロセス・シークレットの漏洩やサービス・コンテナ権限でのコマンド実行を引き起こす可能性がある。この問題はバージョン 1.82.0-stable 以前に影響を及ぼすが、バージョン 1.82.0-stable で修正されている。
Web UI の「Run Test」では、禁止パターンのリストに基づくコード検証が行われ、実行前に “builtins” を取り除くことで、”import”／”os”／”subprocess” などをブロックする仕組みとなっていたが、登録エンドポイント (POST /guardrails) では、いずれの保護機能も適用されていなかった。研究者たちによる概念実証 (PoC) では、Guardrail の登録時にコードが実行され、LiteLLM コンテナから “uid=0(root)” が返された。
実際の影響は、コンテナの実行時設定／マウントされたシークレット／Kubernetes のサービスアカウント・トークン／ネットワーク経由で到達できる範囲／クラウド IAM ロールの権限に応じて異なる。コンテナ内で root 権限を取得しても自動的にホスト上の root 権限を取得できるわけではないが、AI／クラウド環境への大きな足掛かりになる可能性があり、ユーザー組織が LiteLLM のマスターキーを変更せずに使用している場合や、認証なしでサービスを運用している場合には、リスクが大幅に高まる。
従来、LiteLLM は、マスターキーが設定されていない場合、未認証アクセスとして扱い、関連する修正が行われる前には、受信したリクエストを送信したユーザーに “PROXY_ADMIN” ロールを割り当てていた。これにより、外部公開されたインスタンスが単なる未認証の API プロキシではなく、リモートから管理可能な管理用ゲートウェイとして機能する可能性があった。その後、LiteLLM は未認証時のデフォルトロールを変更し、Guardrail の操作に対する管理者権限の確認を強化した。
LiteLLM のパススルー・エンドポイントに関連するクラウド認証情報の窃取シナリオについても、研究者は指摘している。この機能を使用する管理者は、内部アドレスを含む URL へ向けたリクエストをプロキシでき、攻撃者が管理者権限を取得した場合には、AWS EC2 IMDS の “169.254.169.254” などのクラウド・メタデータ・サービスを標的とする経路を設定し、一時的な IAM 認証情報を取得する可能性がある。
この動作自体は単独の脆弱性ではなく、管理機能の問題として位置付けられている。しかし、デフォルトの認証情報／認証なしの状態などの脆弱性により、攻撃者に管理者権限を取得された場合には危険な機能となる。
関連する認可の脆弱性 CVE-2026-35029 では、LiteLLM の “/config/update” エンドポイントに存在する認可チェックの欠如により、認証済みユーザーが悪用する可能性があった。Red Hat によると、この脆弱性によってプロキシおよび環境変数が変更され、リモート・コード実行／権限のないサーバ・ファイルへのアクセス／特権アカウントの乗っ取りにつながる可能性がある。
LiteLLM を運用している組織に対して強く推奨されるのは、直ちにバージョン 1.84.0 以降へアップグレードして MCP の認証バイパスを修正し、Custom Code Guardrails の修正についても 1.82.0-stable 以降を使用していることを確認することである。それに加えて、導入しているリリースに CVE-2026-35029 の修正が含まれているかを確認する必要がある。
管理者に求められるのは、”sk-1234″ を強力で一意なマスターキーに変更し、MCP が必須でない場合に “/mcp/” へのアクセスを無効化または制限するとともに、設定済みの MCP サーバおよびツールの権限を監査し、既存の Guardrail およびパススルー経路を監査することである。
LiteLLM ゲートウェイは、アプリケーションのワークロード／モデル・プロバイダー／クラウド認証情報／プロンプト／内部ツール／自動化システムの間に位置する。したがって、Tier-1 インフラとして扱う必要があり、セキュリティ対策が不十分なゲートウェイは、攻撃者にとって従来の API プロキシよりもはるかに価値の高い標的となる。
LiteLLM AI ゲートウェイにおけるデフォルトキーの不正利用や認証の欠如、および MCP や Custom Code Guardrails に関連する脆弱性 CVE-2026-59822／CVE-2026-59821／CVE-2026-35029 の存在が報告されています。これらにより、LLMjacking や機密認証情報の漏洩、コンテナ内での root 権限によるコード実行が発生し、CISA KEV カタログにも追加されています。対応策として、最新バージョンへのアップデート、マスターキーの変更、MCP へのアクセス制限、不要なパススルー経路の監査が推奨されます。
IoT OT Security News 
You must be logged in to post a comment.