脆弱性 / VULNERABILITY / AI INFRA
公開LiteLLMの約1割が初期設定の管理鍵「sk-1234」を受け入れ — Wizが認証バイパスからクラウド侵害への連鎖を報告
Wiz Researchは2026年9月9日、オープンソースのAIゲートウェイLiteLLMの公開インスタンス約3,000件を調査し、9.6%がドキュメントのサンプル鍵「sk-1234」または認証なしで管理者アクセスを許していたと報告した。認証バイパスCVE-2026-59822と権限昇格を伴うコード実行CVE-2026-59821を連鎖させると、APIキーの窃取やクラウドのIAM認証情報の取得に至るとしている。
要点
- Wiz Researchは2026年9月9日、AIゲートウェイ LiteLLM の公開インスタンスをめぐる調査結果を公表した。2026年2月にShodanで約3,074件を走査したところ、9.6%にあたる294件がサンプル管理鍵「sk-1234」または認証なしで管理者アクセスを許容していた。
- 「sk-1234」はLiteLLM自身のセットアップガイドに例として記載されている値で、Wizによれば同ガイドは2026年9月9日時点でも同じ例示を掲載しつつ、実運用前に長いランダム値へ置換するよう注意書きを添えていた。
- 取得した管理者権限からは、MCP(Model Context Protocol)の認証バイパスCVE-2026-59822 や、カスタムコード・ガードレール経由のコード実行CVE-2026-59821、さらにパススルー経路を悪用したクラウドのIAM認証情報の窃取が可能になるとWizは説明している。
- Wizが報告した脆弱性はいずれも修正済みで、CVE-2026-59822とCVE-2026-42271は1.84.0系、CVE-2026-59821は1.82.0-stable、CVE-2026-40217は1.83.10で修正されている。Wizは管理鍵を初期値から置換し、1.84.0以降へ更新することを推奨している。
何が見つかったのか — 9.6%が初期鍵または無認証で管理者に
Wizは、クラウド環境の約3分の1で利用されているとされるオープンソースのAIゲートウェイLiteLLMについて、インターネットに公開されたインスタンスの認証状況を2月に1回走査した。3,074件中294件(9.6%)が管理鍵「sk-1234」を受け入れ、このうち191件はそもそも管理鍵が未設定で任意の値を受け入れる状態だった。残りはサンプル値がそのまま残置されていた。
Wizが2026年8月に実施した2回目の走査では85,000件超が見つかったが、大半がハニーポットやテスト環境とみられ、2月の数値と単純比較はできないと同社は説明している。現時点の正確な公開数は不明である。
LiteLLMは、100以上のLLMプロバイダへの統一APIやAPIキーの集中管理、予算制御、ガードレール、MCP経由の外部ツール連携などを提供する。Wizは、管理者権限が奪われると全プロバイダのAPIキーの窃取、送受信されるプロンプトと応答の閲覧、MCPで接続されたJiraやSlack、データベースなどへの到達が起こり得ると指摘している。従来知られる**LLMjacking(被害者の課金でモデルを利用する悪用)**に留まらず、クラウド環境自体の侵害に発展し得る点が問題だとしている。
脆弱性の連鎖 — MCPバイパス、ガードレールのRCE、パススルー経由の認証情報窃取
Wizは、Claude Codeを用いたコードレビューで攻撃面を洗い出し、MCP認証、ガードレール、パススルー経路の3機能に起因する問題を報告した。
MCP認証バイパス CVE-2026-59822
LiteLLMのMCPエンドポイントは、独自の認証ハンドラを用いる。BearerトークンがLiteLLMのAPIキーとして検証に失敗した場合、HTTP 401/403を捕捉して空の認証オブジェクトを返すフォールバック処理があり、1文字のBearerトークンでも有効なMCPセッション(mcp-session-id)が成立する。
- 影響: 任意のトークンでMCPセッションを確立し、接続先のMCPサーバが公開するツール(データベース照会、GitHub操作、ファイル操作など)を実行できる。組織が
allow_all_keysで全キーにMCPサーバを開放している場合は影響が拡大する。 - 対象: 1.84.0より前のバージョン。1.84.0で修正され、CISAは2026年9月2日に同CVEをKEV(悪用確認済み脆弱性カタログ)へ登録した。Wizは同社のハニーポットで同年7月7日以降、1文字トークンでモデル一覧を探索する悪用を観測している。
カスタムコード・ガードレール経由のコード実行 CVE-2026-59821
管理者が推論の前後で実行するポリシー(ガードレール)のうち「Custom Code Guardrails」は、サーバ側でPythonコードをexec(compile(...))で実行する。Web UIの「Run Test」では禁止パターン検査と__builtins__の除去によるサンドボックスが適用されるが、ガードレール登録エンドポイント POST /guardrails では同検査とサンドボックスが適用されていなかった。
- 影響: 管理者権限で任意のPythonコードがコンテナ内で実行され、Wizの検証では
uid=0(root)で実行された。 - 対象と修正: 1.82.0-stableより前のバージョンが対象。修正PR #22095で、登録経路でも禁止パターン検査と
__builtins__の除去が適用され、かつ同エンドポイントはPROXY_ADMIN権限が要求されるよう変更された。1.82.0-stableで修正されている。
なおWizは、1.81.8以上1.83.10未満ではサンドボックス自体をバイトコード手法で回避できる別件CVE-2026-40217が存在し、同環境では管理者権限でサンドボックス外の実行が可能だったことも付記している。CVE-2026-40217は1.83.10で修正済みである。
パススルー経路でのクラウド認証情報窃取(CVEなし)
LiteLLMのパススルーエンドポイントは、管理者が任意のURLへの転送経路を作成できるプロキシ機能だが、転送先URLがプライベートアドレスやlocalhost、クラウドのメタデータサービス(169.254.169.254)かどうかの検証を行わない。管理者は転送先をインスタンスメタデータサービスへ向け、x-pass-接頭辞で任意ヘッダを付与するLiteLLMの仕様を悪用してIMDSv2が要求するヘッダも付与し、IAM認証情報を取得できる。
- 位置付け: Wizによれば、この挙動はLiteLLMの脅威モデルで「管理者は信頼される」として意図された動作とみなされ、CVEは付与されていない。そのためパッチによる修正はなく、管理者権限取得後は現在でも悪用可能な設計である。ただし管理鍵が初期値のまま、または未設定で管理者権限を誰でも取得できる状態と組み合わさると、実質的に認証なしでクラウド認証情報の窃取に至る。
- IMDSv2の回避: IMDSv2への切替だけでは緩和にならないとWizは指摘している。
このほかWizは、認証済みの任意ユーザがホスト上でコマンドを実行できたMCPテストエンドポイントの脆弱性CVE-2026-42271(1.74.2以上1.83.7未満、1.83.7で修正)についても整理している。同CVEはStarletteのホストヘッダ脆弱性CVE-2026-48710と連鎖すると認証なしでの実行に悪用可能で、Wizのハニーポットでは暗号資産マイナーの設置に使われた例が観測された。Microsoftも2026年8月に、公開LiteLLM経由で同連鎖を用い、コンテナ環境変数やPostgreSQLの接続文字列から認証情報を窃取した事例を公表している。
修正状況とWizが推奨する対応
Wizが報告した脆弱性は、LiteLLM側でいずれも修正済みである。主要なバージョン対応はWizの整理によれば次のとおりである。
| 脆弱性 | 内容 | 影響バージョン | 修正バージョン |
|---|---|---|---|
| CVE-2026-59822 | MCP認証バイパス — 任意のBearerトークンでMCPセッション成立 | 1.84.0より前 | 1.84.0 |
| CVE-2026-42271 | MCPテストエンドポイントのコマンド実行 | 1.74.2以上1.83.7未満 | 1.83.7 |
| CVE-2026-59821 | ガードレール登録経路のコード実行 | 1.82.0-stableより前 | 1.82.0-stable |
| CVE-2026-40217 | ガードレール・サンドボックスの回避 | 1.81.8以上1.83.10未満 | 1.83.10 |
Wizは、管理鍵(master key)が未設定の場合は全リクエストがPROXY_ADMINとして扱われた点も含め、認証を有効化し、管理鍵をサンプル値「sk-1234」から長いランダム値へ置換すること、および1.84.0以降へ更新することを推奨している。パススルー経路によるメタデータサービスへの到達については設計上の挙動のため、ネットワーク側での** egress 制御やIMDSへの到達制限の併用**が有効になるとしている。
CISAはCVE-2026-59822をKEVへ登録し、連邦民間機関に対し2026年9月16日までの対応を求めている。Wizは同CVEの野外での悪用をハニーポットで確認しており、公開LiteLLMの運用者は速やかな更新と鍵の見直しが求められる。
出典
この記事は、公開情報と編集部の調査・知見をもとに構成しています。内容は公開時点の情報に基づく解説であり、個別の環境への診断・対応を保証するものではありません。重要な判断では、記事内の出典や各提供元の最新情報もご確認ください。