公開されたLiteLLMの約1割で初期サンプル鍵「sk-1234」が通用、クラウド侵害やAPI悪用のリスクが判明
要点
- クラウドセキュリティ企業Wizの調査により、インターネット上に公開されているオープンソースAIゲートウェイ「LiteLLM」の約1割で、公式セットアップガイドに例示された管理者キー「sk-1234」が受け入れられる状態だったことが明らかになった。
- 管理者権限が悪用された場合、サーバー内に保持された各AIプロバイダーのAPIキーやプロンプト履歴が窃取されるほか、クラウド環境のIAM認証情報の取得やコンテナ内でのコード実行につながる危険性が確認された。
- 開発元は設定不備による問題を脆弱性の対象外と定めているが、利用者がマスターキーを独自のランダムな値に変更することで、今回指摘された一連の攻撃経路を遮断できる。
クラウドセキュリティ企業のWiz Researchは、オープンソースのAIゲートウェイ「LiteLLM」に関するセキュリティ調査結果を公表した。同社が2026年2月にインターネット公開サーバーを調査したところ、約1割の環境で公式ガイドのサンプル管理者キーがそのまま通用することが判明したという。認証を突破された場合、AI利用料の不正転嫁（LLMjacking）やクラウドインフラ全体の権限掌握に発展する恐れがあると報告されている。
約1割のサーバーで初期キーや未認証状態を放置
LiteLLMは、社内アプリケーションと各AIモデルプロバイダーの間に配置し、API呼び出しを一元管理するためのオープンソースソフトウェアである。
Wizが2026年2月に検索エンジンShodanを用いて調査したところ、インターネット上に公開されていた3,074台のLiteLLMゲートウェイのうち、約1割にあたる294台でサンプルキー「sk-1234」が受け入れられる状態だった。内訳としては、191台でマスターキーが全く設定されておらず、どのようなキーでも認証を通過できる状態だったほか、残る103台では公式の導入手順に記載された文字列がそのまま設定されていた。
なお、同社が8月に実施した2回目のスキャンでは8万5,000件以上のインスタンスが検出されたものの、その大半はハニーポットやテスト環境とみられ、2月の調査結果とは単純比較できないとしている。LiteLLMの公式セットアップガイドには、本番環境で使用する前に長いランダムな値へ変更するよう注記が添えられているものの、9月9日時点でも例示として「sk-1234」の記載が残されている。
マスターキーの侵害がもたらす影響
LiteLLMにおいてマスターキーは、管理者認証情報であると同時に、システム全体の認証機能を有効化するためのスイッチとしても機能する。バージョン1.82.0-stable以前では、マスターキーを設定せずに起動したゲートウェイは、外部からのすべてのリクエストを管理者として扱っていた。
このキーを掌握した第三者は、ゲートウェイ経由で利用可能なすべてのAIプロバイダーのAPIキーを読み取れる状態となる。また、システムを通過するプロンプトや応答内容の閲覧、Model Context Protocol（MCP）経由で接続された内部ツールへのアクセスも可能になる。窃取されたAPIキーが悪用された場合、攻撃者のAIワークロードの利用料金が被害者側に請求される「LLMjacking」と呼ばれる被害が発生する。
パススルー機能を介したクラウド認証情報の取得
Wizの検証では、AIのAPIキー窃取にとどまらず、ゲートウェイが稼働するホストマシンのクラウド権限を奪取する経路も実証された。
LiteLLMには、管理者が指定した任意のURLへリクエストを転送する「パススルーエンドポイント」機能が備わっている。この転送先URLに対しては、プライベートIPアドレス、ローカルホスト、クラウドのメタデータアドレスに対する制限チェックが行われていない。そのため管理者は、インスタンスメタデータサービス（IMDS）へリクエストを転送させ、マシンに割り当てられたIAM認証情報を読み出すことが可能となっている。
また、LiteLLMの仕様上、「x-pass-」プレフィックス付きのヘッダーはプレフィックスを除去して転送先に渡されるため、AWSのIMDSv2で要求されるヘッダーの付与にも対応できてしまうという。
現時点で実際の攻撃被害は報告されておらず、本手法はPoC（概念実証）の段階にとどまる。また、LiteLLMのセキュリティモデルでは管理者を信頼された主体として扱っているため、本機能は設計通りの挙動と見なされており、CVE番号の割り当てや修正対応は行われていない。公式のセキュリティポリシーにおいても、マスターキー未設定などの設定ミスに起因する攻撃は「明示的に対象外」と定義されている。
ガードレール機能の脆弱性と深刻度を巡る見解の相違
今回の調査では、リモートコード実行に関する脆弱性「CVE-2026-59821」についても言及されている。
バージョン1.82.0-stable以前の環境では、カスタムコードガードレールを作成・更新するエンドポイントにおいて、テスト用エンドポイントで実施されていたサンドボックスやパターンチェックが省略されていた。これにより、管理者権限を持つ攻撃者がコンテナ内で任意のPythonコードを実行できる状態になっていた。マスターキーが未設定のサーバーでは、すべてのアクセスが管理者として扱われていたため、外部から直接コード実行エンドポイントへ到達可能だったという。
Wizはこの問題を「root権限での認証後コード実行」と位置づけ、コンテナ内でroot権限（uid=0）を取得できる実証結果を示した。一方で、LiteLLMメンテナーが公開したアドバイザリでは、高特権アカウントを前提とした欠陥であるとして、CVSSスコアを「Low（2.1）」と評価しており、深刻度の捉え方に違いが見られる。
Wizはバージョン1.82.0以降ではコード実行がサンドボックス内に制限されたとしているが、5月に公開された別のアドバイザリ（CVE-2026-40217）によると、バージョン1.81.8から1.83.10未満の環境では、バイトコード手法を用いてサンドボックスを回避し、デフォルトでroot権限動作するプロキシプロセス内でコードを実行できる問題が存在していたことも明らかになっている。
対策方法
今回報告された攻撃経路はいずれも管理者権限の取得を前提としているため、ソフトウェアのアップデートを行わなくとも、設定ファイル内のマスターキーを推測困難な値に変更するだけでリスクを回避できるとされている。