インターネットに公開されているLiteLLM AIゲートウェイのうち、およそ10台に1台が、広く知られているデフォルトのマスターキー「sk-1234」を受け入れるか、あるいは認証を一切要求しない状態だったことが判明しました。これにより、LLMjacking(LLMの不正利用)、機密性の高い認証情報の露出、さらには脆弱なバージョンではゲートウェイコンテナ内でのroot権限によるコード実行にまで直結する経路が生まれていました。
公開されている3,074台のインスタンスを対象にインターネットスキャンを実施したところ、294台(9.6%)がデフォルトキーを受け入れており、191台(6.2%)は認証が有効になっていないことが分かりました。
外部から到達可能な問題の中で最も深刻なのは、CVE-2026-59822として追跡されている脆弱性で、LiteLLMのModel Context Protocol(MCP)Streamable HTTPエンドポイントに影響します。
LiteLLM 1.84.0より前のバージョンでは、攻撃者が任意のBearerトークンを送信することで、APIキー検証の失敗を空の認証済みユーザーオブジェクトに変換してしまうOAuth2フォールバック経路を発動させることが可能でした。
実際には、わずか1文字のトークンであっても有効なMCPセッションを確立でき、正規のLiteLLMキーを持たずに設定済みのMCPツールにアクセスできてしまいます。
これが重大である理由は、MCPサーバーが単なるデータだけでなく、アクション(操作)そのものを公開している場合が多いためです。デプロイ構成によっては、侵害されたゲートウェイを通じて、内部データベース、ソースコードリポジトリ、チケット管理システム、Slackワークスペース、ファイルストア、CI/CDツール、その他の連携済み企業サービスへのアクセスが可能になる恐れがあります。
Datagovernance consulting
この脆弱性は、実際の悪用が観測されていることを示す形で、CISAの既知の悪用された脆弱性(KEV)カタログに追加されています。
2つ目の問題であるCVE-2026-59821は、LiteLLMのCustom Code Guardrails(カスタムコードガードレール)機能に影響していました。
本番環境の作成・更新エンドポイントは従来、送信されたPythonコードをコンパイル・実行する際に、UIのテストワークフローで適用されるサンドボックス化や危険なパターンの検証を行っていませんでした。
Wizの研究者らは、LiteLLMに影響する複数の脆弱性を特定しました。LiteLLMは、OpenAI、Anthropic、AWS Bedrock、Azure、Google Vertex AIといったLLMプロバイダーへのアクセスを一元管理するために利用されているオープンソースのゲートウェイです。
LiteLLM AIゲートウェイ
ガードレールを作成または変更できる権限を持つユーザーであれば、LiteLLMプロキシ環境内でPythonコードを実行できてしまい、プロセスのシークレット情報が露出したり、サービスコンテナの権限でコマンドが実行されたりする可能性がありました。
この問題は1.82.0-stableより前のバージョンに影響しており、1.82.0-stableで修正済みです。
Web UIの「Run Test」ボタンは、実行前にコードを禁止パターンのリストと照合し、__builtins__を除去することで、import、os、subprocessなどの使用をブロックします。しかし、登録用エンドポイント(POST /guardrails)にはこれらの保護策のいずれも適用されていませんでした。
研究者らが作成した概念実証では、ガードレール登録時にコードが実行され、LiteLLMコンテナからuid=0(root)という結果が返されました。
実際の深刻度は、コンテナのランタイム構成、マウントされているシークレット、Kubernetesサービスアカウントのトークン、ネットワークへの到達可能性、クラウドのIAMロール権限によって左右されます。
コンテナ内でのroot権限は、必ずしもホスト上でのroot権限を意味するわけではありませんが、それでもAIやクラウド環境における影響の大きい足がかりになり得ます。
組織がLiteLLMのマスターキーをデフォルトのまま変更していなかったり、認証なしでサービスを運用していたりする場合、このリスクは大幅に増大します。
従来、LiteLLMはマスターキーが未設定の状態を未認証アクセスとして扱っており、該当の修正が行われる以前は、受信したリクエストに対してPROXY_ADMINロールを割り当てていました。
これにより、公開状態のインスタンスは、単なる未認証のAPIプロキシではなく、リモートから管理操作が可能な管理者用ゲートウェイと化してしまう恐れがありました。
その後LiteLLMは、未認証時のデフォルトロールを変更し、ガードレール操作に対するより強力な管理者チェックを追加しました。
研究者らはまた、LiteLLMのパススルーエンドポイントに関連するクラウド認証情報の窃取シナリオについても指摘しています。この機能により、管理者は内部アドレスを含む指定URLへリクエストをプロキシすることができます。
攻撃者が管理者権限を取得した場合、AWS EC2 IMDS(169.254.169.254)などのクラウドメタデータサービスを標的とするルートを設定し、一時的なIAM認証情報を取得できる可能性があります。
この挙動は独立した脆弱性というより管理機能として位置付けられているものですが、デフォルトの認証情報、認証の欠如、あるいは他の認可上の不備によって管理者アクセスが取得された場合には、危険なものとなります。
Hacking& Cracking
関連する認可の問題であるCVE-2026-35029では、認証済みユーザーがLiteLLMの/config/updateエンドポイントに存在する認可チェックの欠如を悪用できる状態でした。
Red Hatによると、この脆弱性はプロキシおよび環境変数の変更を許してしまう可能性があり、リモートコード実行、サーバー上のファイルへの不正アクセス、特権アカウントの乗っ取りにつながる恐れがあるとしています。
LiteLLMを運用している組織は、MCP認証バイパスに対処するため直ちにバージョン1.84.0以上へアップグレードするとともに、Custom Code Guardrailsの修正が適用された1.82.0-stable以降を実行していることを確認する必要があります。
また、CVE-2026-35029に対する修正が自社のデプロイ済みリリースに反映されているかどうかも確認すべきです。
管理者は、sk-1234を強力で一意なマスターキーに置き換えるとともに、MCPが必須でない場合は/mcp/へのアクセスを無効化または厳格に制限し、設定済みのMCPサーバーとツール権限を監査し、既存のガードレールとパススルールートを点検する必要があります。
LiteLLMゲートウェイは、Tier-1(最重要階層)のインフラとして扱われるべきです。アプリケーションのワークロード、モデルプロバイダー、クラウド認証情報、プロンプト、内部ツール、自動化システムの間に位置しているため、セキュリティ対策が不十分なゲートウェイは、通常のAPIプロキシよりもはるかに攻撃者にとって価値の高い標的となります。
★ Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.
翻訳元: https://gbhackers.com/litellm-ai-gateways/
