LiteLLMの実測で公開ゲートウェイの9.6%がデフォルトキーを受け入れ、MCPの脆弱性により任意のtokenが有効なセッションに

Wizは9月9日、LiteLLMの[攻撃対象領域に関する調査](https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise)を公開した。研究者らは2026年2月、Shodanを通じて公開されている3,074件のゲートウェイを発見した。このうち294件、すなわち9.6%が、ドキュメントのサンプルで使用されている管理キー`sk-1234`を受け入れるか、認証を要求していなかった。後者は191件だった。今回注目すべき内容は新たなCVEではなく、公開デプロイメントの測定とハニーポットによる観測だ。Wizによると、MCP認証バイパスはすでに実際に悪用されている。

中核となる脆弱性CVE‑2026‑59822は、MCP Streamable HTTPの独立した認証経路に存在する。システムは当初、認識できないBearer tokenを上流のOAuth2 tokenとして渡せるようにしていたが、失敗時の分岐で空の`UserAPIKeyAuth`オブジェクトが作成されていた。そのため、攻撃者は任意のtokenを使って認証済みセッションを確立し、ゲートウェイに接続されたMCPツールを列挙して呼び出すことができた。[GitHub Security Advisory](https://github.com/advisories/GHSA-7488-6r32-c95q)は、この脆弱性をCVSS 8.8と評価している。影響を受けるのは1.84.0未満のバージョンで、修正版ではこのfallback経路が遮断される。

第2の攻撃チェーンはCustom Code Guardrailsに関係する。旧バージョンの本番用作成・更新endpointには、テストendpointで使用されていたsandboxと検証が適用されておらず、権限を持つ呼び出し元はサーバー上で実行されるPythonコードを送信できた。さらに旧バージョンでは、master keyが設定されていない場合、匿名リクエストが`PROXY_ADMIN`として扱われていた。このCVE‑2026‑59821は1.82.0で修正されている。サービスがデフォルトキーを残したまま旧バージョンを運用している場合、本来は認証後にのみ可能なコード実行が、実質的に未認証に近い攻撃へと悪化する可能性がある。

Wizはさらに、pass-through endpointが任意のURLを指定でき、AWS instance metadataにさえアクセス可能だと指摘した。管理者権限があれば、headerを転送することでIMDSv2 tokenフローを完了できる。この機能は脆弱性として分類されていないため、アップグレードだけではすべてのリスクを排除できない。運用担当者は少なくとも1.84.0以降へアップグレードし、master keyとモデルプロバイダーのキーをローテーションするとともに、管理用routeとMCP routeをインターネットから切り離し、ネットワークポリシーでlink-local metadataへのアクセスを遮断すべきだ。スキャン結果の数値は調査時点で外部から確認できたインスタンスのみを示している。また、「コンテナのroot権限を取得できる」かどうかは、バージョン、実行ユーザー、デプロイ時の権限に依存するため、すべてのLiteLLM環境を直接乗っ取れると一般化することはできない。