AIゲートウェイ侵害で鍵まで流出、LiteLLM公開運用の盲点

Microsoftは2026年8月26日、インターネットに公開されたLiteLLMゲートウェイの侵害で、モデル提供者のAPI鍵やデータベース内の仮想鍵が収集され、攻撃者の管理下へ送信された事例を公表した。Microsoft Security Researchの脅威分析 では、秘密情報の窃取に加え、暗号資産マイナーの実行とSSH鍵などによる永続化も確認されている。

初期侵入は、LiteLLMのCVE-2026-42271とStarletteのCVE-2026-48710を組み合わせた経路と整合すると、Microsoftは高い確度で評価した。ただし、侵害時のHTTP要求を完全に特定したとの断定ではない。公開中の環境では、修正版への更新だけでなく、流出した可能性がある鍵の失効、管理面の閉鎖、データベースと外向き通信の分離までが対応範囲となる。

認証付き機能が未認証のコマンド実行経路に

CVE-2026-42271は、MCPサーバーを保存前に試す二つのPOSTエンドポイントに存在した。LiteLLM 1.74.2から1.83.6では、要求本文のcommand、args、envを使って、ゲートウェイのプロセス権限でサブプロセスを起動できた。単独では有効なプロキシAPI鍵が必要だったものの、管理者と低権限利用者を分ける認可も不足していた。

ここに、Starletteが不正なHostヘッダーから組み立てたURLを認証判定に使うCVE-2026-48710が重なる。認証ミドルウェアには公開パスへの要求と認識させながら、ルーターには本来のMCPテスト用パスを処理させられるためだ。Horizon3の検証 は、Starlette 1.0.0以下を依存関係に含む脆弱なLiteLLMで、資格情報なしのリモートコード実行が成立すると確認している。

二つの欠陥を分けて考えると、攻撃連鎖が見えやすい。Starlette側の不備が認証境界を越える入口となり、LiteLLM側のMCPテスト機能がOSコマンドの実行能力を与える。侵入後の処理はLiteLLMゲートウェイ自身の権限で動くため、そのプロセスから見える秘密情報と接続先が、そのまま被害範囲になり得る。

環境変数からPostgreSQLへ窃取範囲が拡大

観測された最初の段階では、ペイロードがゲートウェイプロセスの環境変数を読み、master、API key、token、passwordなどに該当する値を抽出していた。対象にはモデル提供者のAPI鍵、LiteLLMのマスターキー、データベース接続文字列、UI資格情報が含まれ、Pythonのurllib、curl、wgetを使う複数の送信経路が用意されていた。

取得されたDATABASE_URLは、LiteLLMが利用するAzure Database for PostgreSQLへの接続にも使われた。攻撃コードはLiteLLM_ProxyModelTableとLiteLLM_VerificationTokenを読み出し、モデル構成、上流プロバイダーの鍵、プロキシが発行した仮想鍵を収集した。出力はBase64で符号化され、小さな単位に分けて外部へ送信されている。

さらに、一時領域への偽装ELFバイナリの配置、XMRigまたは類似するマイナーの実行、競合マイナーの排除が確認された。サービスアカウントのauthorized_keys変更、隠しファイルからの再実行、ファイルを変更しにくくする属性の設定もあり、攻撃目的は資格情報の窃取、計算資源の収益化、アクセスの維持にまたがっていた。

被害半径を決めるのはゲートウェイ周辺の権限

直接確認すべきなのは、影響を受けるLiteLLMとStarletteを組み合わせ、MCPテスト用エンドポイントへ外部から到達できる構成だ。ただし、侵入後の被害は製品バージョンだけでは決まらない。上流API鍵をプロセス環境へ置き、広いデータベース権限と自由な外向き通信を同じ実行環境に与えていれば、一つのプロセス侵害から資格情報の流出とデータ層への到達が連続する。

Kubernetes上では、Podにマウントされたサービスアカウントトークン、Secret、設定ファイルも到達可能な資産になり得る。Cloud Security Allianceの技術資料 も、LiteLLM 1.83.7未満とStarlette 1.0.1未満の更新に加え、MCPテスト機能の公開範囲、シークレット管理、ネットワーク分離を点検対象に挙げている。

この構造が、公開運用の盲点となる。LiteLLMは単にHTTP要求を転送するだけでなく、複数のモデル提供者に向かう資格情報、ルーティング設定、要求と応答、バックエンド接続が交差する制御点である。通常のプロキシと同じ公開・権限設計では、侵害時に一つのアプリケーションを超えて影響が広がる。

更新と封じ込め、鍵交換を同時に進める

修正版はLiteLLM 1.83.7以上とStarlette 1.0.1以上で、両方を独立した対応項目として扱う必要がある。即時更新が難しい場合は、POST /mcp-rest/test/connectionとPOST /mcp-rest/test/tools/listをリバースプロキシなどで遮断できるが、これは新たな侵入を抑える暫定策にすぎない。

すでに公開していた環境や侵害の兆候がある環境では、優先順位は次のようになる。

1. 管理面とMCPテスト用エンドポイントへの外部通信を遮断し、対象ホストやPodの不要な外向き通信を止める。
2. 必要なログ、プロセス情報、コンテナの状態を保全し、LiteLLMとStarletteを修正版へ更新する。
3. モデル提供者のAPI鍵、LiteLLMマスターキー、仮想鍵、データベース資格情報を失効・再発行する。新しい鍵は侵害の疑いが残る実行環境へ戻さない。
4. 専用サービスアカウントと最小限のデータベース権限へ切り替え、データベースを私設接続に置く。外向き通信は必要なモデル提供者などに限定する。
5. クリーンなイメージから再構築し、SSH鍵、cron、隠し実行ファイル、永続ボリューム、クラウド監査ログを確認してから復旧する。

パッチは、すでに外部へ送られた鍵や設置済みの永続化機構を無効にしない。したがって、バージョン更新の完了をインシデント対応の終了条件にせず、資格情報の交換と実行環境の再構築までを一続きの復旧作業として扱う必要がある。

SOCが追うべき痕跡と未公表の範囲

検知では、LiteLLMプロセスを親とするbash、sh、Python、curl、wgetの起動を、秘密情報へのアクセスや外向き通信と関連付ける。コンテナでゲートウェイがPID 1なら、/proc/1/environの読み取りは優先度の高い痕跡となる。DATABASE_URL、LiteLLM固有のテーブル名、一時領域からの実行も同じ時間軸で確認したい。

ネットワーク側では、二つのMCPテスト用パスへのPOST、不正なHostヘッダー、通常のモデル提供者以外へのDNS問い合わせやHTTP通信が手掛かりになる。ホスト側ではauthorized_keys、cron、隠しファイル、実行権限、変更を妨げる属性の差分を追う必要がある。

公表資料は攻撃連鎖と防御策を詳述した一方、被害組織名、侵害されたゲートウェイや流出した鍵の総数、攻撃主体の帰属を明らかにしていない。既知の二つの脆弱性が初期侵入に使われたとの判断も高い確度の評価であり、断定ではない。今後は追加の被害範囲や攻撃主体に関する情報とともに、公開中のAIゲートウェイがどこまで縮小・分離されるかが焦点となる。