Wiz：インターネットに公開されたLiteLLMゲートウェイのほぼ10分の1が、サンプルの管理者キーsk-1234を受け入れています

2026年9月9日、Wiz Researchは、アプリケーションと、アプリケーションが利用料を支払うモデルプロバイダーとの間に位置するオープンソースAIゲートウェイLiteLLMに関する調査を公表し、公開インターネット上で到達できた3,074件のLiteLLMデプロイメントのうち294件——9.6%、ほぼ10件に1件——がsk-1234——プロジェクト自身のセットアップドキュメントに記載された例示マスターキー——を受け付けたか、認証情報を一切要求しなかったと報告した。この文字列は通常のAPIキーではない。LiteLLMでは、これは管理者認証情報であると同時に認証を有効にするスイッチでもあるため、これを提示した者は、ゲートウェイに保存されたすべてのモデルプロバイダーキーを読み取り、そこを通過するすべてのプロンプトと補完を監視し、Model Context Protocol経由で接続されたすべてのツールサーバーに到達できる。Wizの共同著者Amitai CohenとYaara Shrikiは、そのアクセスをルート権限でのコード実行と、ホストのクラウドIAM認証情報の窃取につなげた。本稿は、Wizの報告書、LiteLLM自身のセキュリティアドバイザリ、およびその後公表されたCISAのKnown Exploited Vulnerabilitiesリストに基づいており、AIインシデントアーカイブは、それぞれ独自の情報源、深刻度、信頼度評価を持つ隣接する記録と並べてこの記録を保持している。

記録に含まれる唯一の日付は公開日であり、それは公開日である。見出しの背後にあるスキャンは2026年2月に実施された。Wizが説明する2つのコード欠陥には、遅くとも5月中旬までに修正が出荷済みで、それはプロジェクト自身の記録が3月と5月としているリリースにおいてだった。CVE識別子は7月に発行され、カタログへの掲載は9月だった。報告書が印刷される時点で、その内容のほとんどはすでに古くなっていた。これこそが報告書の主張の大部分を占めている。

9.6%という数字は1回のスキャンによるものであり、Wizは同社が独自に行った8月の追加調査はこれと比較できないと述べている

この測定は単純で、Wizはその手法を率直に示している。2026年2月にShodanで見つかったインターネット公開のLiteLLMプロキシ3,074件を対象に、それぞれが文書化された例示キーで認証するかどうかをテストした。そのうち294件が認証した。このグループのうち、191件はマスターキーがまったく設定されておらず、提示された任意の文字列を受け入れたはずだった。残りはセットアップガイドのプレースホルダーをそのまま残していた。どちらの失敗モードもソフトウェアのバグを必要としない。どちらも必要なのは、ゲートウェイのアドレスと、プロジェクト自身のREADMEに記載された値だけだ。

これは単一ベンダーのスキャンでもある。Wizの数字は、9月10日にCloud Security AllianceのAI Safety Initiativeによって、また同日にThe Hacker Newsによって繰り返されているが、どちらも出典を明示して繰り返しているものであり、この記事のために3,074という数字の独立した再現は見つからなかった。Wizは2026年8月に2回目のスキャンを実施し、85,000件超のインスタンスを発見した。これは2月の件数の約27倍である。同社によると、それらの大半はハニーポットまたはテスト配備である可能性が高く、2つの件数は比較できないという。現在の露出数を示す数字はなく、それを引用する記事は2月の数字を引用していることになる。

報告書に載っているもう一つの数字は、スキャンによるものではなくWiz自身のテレメトリに基づくものである。同社によれば、同社が観測するクラウド環境のおよそ3分の1にLiteLLMが存在するという。これはベンダーが自社の顧客基盤について述べた見解であり、鵜呑みにはせず一定の距離を置いて受け止めるべきだが、研究者たちがゲートウェイの設定不備をアプリケーションの問題ではなくクラウドの問題として扱った理由を説明するものでもある。

マスターキーは管理者用の認証情報であると同時に、認証を有効にするスイッチでもあります。

LiteLLMの設計では、1つの秘密に2つの役割がある。マスターキーは管理リクエストを認証し、その存在が認証自体を可能にする。マスターキーもJWTもOAuth2設定もない場合、プロキシはオープンな状態で動作し、すべてのリクエストを受け入れる。WizはAnthropicのClaude Codeを使ってコードベースを調べ、ユーザーが制御する入力を受け取って実行コンテキストに渡す機能を探したが、認証ハンドラーは同社が指摘した3つのサーフェスの1つだった。

v1.82.0-stable より前では、その2番目のジョブの結果はオープンプロキシよりも悪いものでした。Wiz は、マスターキーが設定されていない場合、認証ハンドラーがすべての受信リクエストに PROXY_ADMIN ロールを割り当てていたため、未認証の呼び出し元は単に受け入れられるだけでなく、管理者として受け入れられていたことを発見しました。報告書で引用されているプルリクエスト #22095 は、デフォルトのロールを INTERNAL_USER に変更し、ガードレールエンドポイントに管理者チェックを追加しました。

ゲートウェイへの管理アクセスは限定的な特権ではない。インスタンスはルーティング先のすべてのプロバイダーのAPIキーを保持しており、そのためLLMjacking——被害者の請求でモデルワークロードを実行する行為——の標的となる。プロンプトと生成結果を目にする。外部のMCPツールサーバーに接続し、内部展開ではそうしたサーバーに課題トラッカー、チャット、データベース、デプロイパイプラインが含まれる可能性が高い。

Wizはまた、その管理権限からホストのクラウドアイデンティティに至る経路も実証した。LiteLLMでは管理者が任意のターゲットURLへのパススルールートを登録でき、ターゲットはプライベートアドレス範囲、localhost、クラウドメタデータアドレスに対して検証されない。ルートをインスタンスメタデータサービスに向けると、ワークロードが実行されているIAM認証情報が返される。メタデータサービスをIMDSv2に切り替えても役に立たない。IMDSv2は通常、別途取得したセッショントークンを要求することでこの種のリクエストフォージェリを防ぐが、LiteLLMはx-pass-という接頭辞が付いた任意のヘッダーを、接頭辞を剥がしてターゲットに転送するため、トークンヘッダーをすり抜けさせられてしまう。Wizは、管理者を信頼する脅威モデルの下ではこの機能は意図どおりに動作していると言うこともでき、そのためCVEも修正もないと述べている。

最後の段落はデモンストレーションであり、実際に観測された攻撃ではない。9月10日にこの研究を報じたHacker Newsは、実際のデプロイに対して誰かがそれを行ったと報告している情報源はないと述べ、またそれにはまず管理者アクセスが必要だとしている。Wizの位置づけも同じだ。パススルーは設計上の性質であり、管理者の認証情報がドキュメントに記載された文字列である場合にのみ脆弱性となる。

8.8と2.1は、異なる出発点から同じチェーンを評価している

2件のCVEが技術的な知見を示しており、その公開スコアはこれ以上ないほど大きく隔たっている。

CVE-2026-59822 は MCP の認証バイパスであり、LiteLLM のアドバイザリでは CVSS 4.0 に基づき High、8.8 と評価されており、必要な権限やユーザー操作、攻撃要件はいずれもありません。MCP エンドポイントは独自の認証ハンドラを備えており、LiteLLM のキー、または上流のツールサーバー宛ての OAuth2 トークンのいずれかを受け付けるように作られています。トークンが LiteLLM の検証に失敗すると、ハンドラは 401 を捕捉し、リクエストを拒否する代わりに空の認証オブジェクトを代入していました。そのため、任意の Bearer トークンが有効な MCP セッションを生成し、1 文字だけでも同様でした。Wiz の実証コードでは、1 文字の Bearer トークンを送信するとセッション識別子が返されます。この脆弱性は 1.84.0 で修正されています。

CVE-2026-59821 はガードレールの欠陥であり、同じプロジェクトのアドバイザリでは Low、2.1 と評価され、高い権限が必要とされ、攻撃要件も存在します。カスタムコードガードレール機能では、管理者が Python を送信し、サーバーがそれをコンパイルして実行します。Web UI のテストエンドポイントでは、コードを禁止パターンリストに対して検証し、実行前に builtins を削除していましたが、本番の作成エンドポイントと更新エンドポイントではどちらも行っていませんでした。Python は builtins が存在しない場合にそれらを再投入するため、送信されたコードは標準ライブラリに到達しました。Wiz の概念実証では、登録時点で、つまりモデルリクエストより前にシェルコマンドを実行するガードレールを登録し、コマンドの出力をブロック理由として返します。そのテストでは root として返ってきました。この欠陥は v1.82.0-stable で修正されています。

2つの説明は両立しており、それを調和させる一文はアドバイザリ自体に含まれている。LiteLLMは、マスターキーが設定されていないデプロイでは呼び出し元がプロキシ管理者として扱われる可能性があると指摘しており、まさにそれがガードレールのエンドポイントを手の届く範囲に置いた。A 2.1 は特権ユーザーを前提としている。Wizの連鎖は、デフォルトキーによってすべての呼び出し元が特権を持つ場合に何が起こるかを示したものだ。どちらのスコアも、それぞれの出発点について誤ってはいない。両者が見解を異にするのは、その立場がどれほど頻繁にコストなしで得られるかという点である。

Wizの「1.82.0以降、デフォルトキーを保持する攻撃者はサンドボックス内でしかコードを実行できない」という主張には、1つ注意点がある。The Hacker Newsが指摘するのは、2026年5月の別のアドバイザリCVE-2026-40217であり、これは1.81.8から1.83.10未満までのバージョンにおいて、バイトコード技法を用いてそのサンドボックスを脱出することを説明している。しかも、そのアドバイザリによればデフォルトのコンテナイメージでrootとして動作するプロキシプロセス内での話である。そのエンドポイントに到達するにはプロキシ管理者の資格情報が必要であり、それはまさにマスターキーにほかならない。

8.8も普遍的なものではない。Cloud Security Allianceのリサーチノートは、GitLabのアドバイザリが同じ脆弱性に対して基本スコア8.2を記載していると指摘し、2つの手法の間でどちらが正しいかを裁定することは避け、両方が高レンジに位置するという点だけを述べている。記録上の重大度「高」は、どちらの数値が用いられるかによって変わるものではない。

1件のCVEが実際の攻撃で悪用されており、デフォルトキーの露出については被害者が特定されていない

CISAは2026年9月2日、CVE-2026-59822をKnown Exploited Vulnerabilitiesカタログに追加し、連邦民間機関向けに2026年9月16日という是正期限を設定した。カタログ項目にはCWE-287とCWE-306（不適切な認証および認証の欠如）が付されている。Cloud Security Allianceの注記によると、業界の追跡調査では、これが同リストに載った最初のMCP固有の欠陥として説明されている。Wizは観測した悪用を公表している。2026年7月7日以降、同社のハニーポットは、モデル一覧取得エンドポイントを探索する単一文字のベアラートークンを含むリクエストを記録しており、Wizはこの欠陥の他の利用については述べていない。

デフォルトキーについては、それに匹敵するものは何も存在しない。被害者は誰も名指しされておらず、sk-1234を通じて乗っ取られたと特定されたゲートウェイもなく、294台のホストが使用されていることを示すテレメトリもない。アーカイブの記録には実際の被害が記されていないが、これはメカニズムについてではなく証拠についての陈述である。露出は測定されたのであり、使用されているのを目撃されたわけではない。

これらと並べて扱われることの多い別の2件は、同じものではない。CVE-2026-42271（2つのMCPテストエンドポイントを介したコマンド実行）は、攻撃者が実際にコードを実行するために悪用したLiteLLMの脆弱性であり、Wizのハニーポットは、それが暗号通貨マイナーをインストールする様子を記録した。Microsoftが公開した2026年8月の事例では、侵入者がゲートウェイコンテナの環境変数を読み取り、マスターキー、プロバイダーキー、データベース接続文字列を取得したうえで、LiteLLMのモデルテーブルと仮想キーテーブルからレコードをコピーしており、これは新たな侵入経路というより、侵害されたゲートウェイがどれほどの価値を持つかを示すものだ。The Hacker Newsは、Microsoftが侵入経路をCVE-2026-42271の連鎖と評価していると報じている。

メンテナの立場は、マスターキーの欠落は脆弱性ではなくセットアップの誤りであるというものです。

LiteLLMのセキュリティポリシーは明確です。対象外の問題として「セットアップ時の設定ミス（例：プロキシ設定で master_key を設定しないこと）を必要とする攻撃」を挙げ、これらは明示的に対象外であり、脆弱性とは見なされないと述べています。Wiz は、パススルー動作を「おそらく意図どおりに動作している」と呼ぶことで、別の方向から整合する結論に達しています。

その立場は公開の場で試された。2026年8月15日、ある研究者がGitHub issue #37054を起票し、LITELLM_MASTER_KEYが未設定のプロキシが任意のキー値で認証を行うこと、および同梱のdocker-composeファイルではこれが設定されていないことを報告した。このissueは30分後にクローズされ、唯一のコメントは同じアカウントによるものだった。そこでは、報告は公開issueではなく非公開の脆弱性報告を通すよう求めるセキュリティポリシーの指示を引用し、公開で起票したことを謝罪し、完全な報告は代わりにアドバイザリの経路で提出していると述べていた。スレッドにはメンテナーの返信はなく、記録上は、プロジェクトがそれに応答したのではなく、報告者が公開報告を撤回したことを示している。非公開の提出がその後どうなったかを記録した公開情報は何もない。

本記事のために、9月のレポートに関するその立場を擁護または修正するBerriAIからの公開声明は確認できなかった。同社の可視的な対応は、文章ではなくリリースノートと設定ファイルの中に表れている。

執行は10月3日、報告の24日後に到来した。

コード上の2つの欠陥は、報告のはるか前に修正されていた。Wizの開示タイムラインには、2026年2月18日に報告され2月25日にv1.82.0で修正されたガードレールのコード実行、4月25日にv1.84.0で修正されたMCPバイパス、7月7日に確認された悪用、7月8日に公開されたCVE識別子、9月2日のカタログ掲載が記録されている。リリース成果物の日付は修正の日付より後になっている。パッケージインデックスではv1.82.0が2026年3月1日、v1.84.0が5月14日となっており、これは各修正が反映された時点ではなく、インストール可能になった時点を示している。ファーストパーティのリリース記録2件は、同じ修正をこのタイムラインより後の日付にしている。GitHub上のv1.82.0-stableリリースは2026年3月11日、PyPI上の1.82.0パッケージは3月1日付で、v1.84.0は両方とも2026年5月14日付となっている。公開されたものの中にこのずれを説明するものはなく、これらの日付はいずれも9月の報告より数か月前なので、議論には影響しない。2件のGitHubアドバイザリはさらに3つ目の日付を加えている。それらは2026年6月30日に公開されており、Wizが7月8日に出たとしているCVE識別子の3週間前である。

これらのリリースのどれも修正しなかったのは、デフォルト値だった。Wizは、9月9日時点で、Docker Composeまたはpip installでLiteLLMをインストールする際のマスターキーが依然としてsk-1234に設定されていたと報告し、The Hacker Newsはその日もセットアップガイドがその値を使っていたことを確認した。この変更は、2026年10月3日にPython Package Indexへアップロードされたv1.104.0で行われ、リリースノートでは破壊的変更として記載されている。プロキシは、未設定、空、または公知のマスターキーでは起動を拒否するようになり、起動エラーで不正な値の発生元を示し、安全なキーを生成するコマンドを表示する。関連する項目には、同梱の設定ファイルや例で公知の弱いマスターキーの値を宣伝しないようにする変更が記録されており、プロジェクトのmainブランチにあるdocker-composeファイルではキーが一切設定されなくなった。

それが守る価値のある順序だ。コードは春にパッチが当てられた。それらのパッチを不十分にした値は10月までインストール手順に残り、その時になって初めてソフトウェアはそれを受け付けなくなった。どちらの修正も、もう一方を待つ必要はなかった。

変わっていないのは、インスタンスメタデータサービスへのパススルー経路です。プロジェクトが管理者を信頼済みとして扱っているため、この経路には依然としてCVEも修正も存在しません。したがってWizの修復リストは主に運用者側の作業です。強力かつ一意のマスターキー、登録済みガードレールの見直しとそれに続くプロセス再起動によるメモリ上に保持されたコードのクリア、コンテナの外向き通信を制限したうえでのパススルーエンドポイントの監査、そして最小権限のIAMロールです。この4つのうち、アップグレードだけで実現するものはありません。

記録が立証していない事柄

• 3,074ホストのスキャンを独立に再現したものは見つからなかった。9.6%はWizによる測定値であり、それに関する他のすべての記述は、この数値をWizのものとして引用している。

• 現在の露出数を示す数字は存在しない。8月の追跡調査では85,000件を超えるインスタンスが見つかったが、Wizによればその大半はハニーポットまたはテスト配備であり、2月の件数とは比較できない。

• 被害者は存在しない。記録の中には、デフォルトキーを通じて侵害されたゲートウェイ、オペレーター、クラウドアカウントを名指しするものは何もなく、Wizが文書化した悪用はsk-1234の悪用ではなくMCPバイパスの悪用である。

• 294台のホストが使用されたという証拠はない。このスキャンはそれらが認証を行うかどうかを試したものであり、誰かが実際に認証したことを示すより弱い主張である。

• ガードレールの欠陥について、確定した深刻度はまだない。Wiz とメンテナーは同じ挙動を説明しながら、その評価を大きく異にしており、その違いは、それぞれが攻撃者にすでにあると想定する権限に関するものだ。

Wizはまた、この種の露出に対する検出機能を販売するクラウドセキュリティベンダーであり、レポートは、同社製品がLiteLLMのデプロイ、脆弱なバージョン、シャドウインスタンスをどのように特定するかに関するセクションで締めくくられている。これは修復セクションを読むための文脈であり、メンテナー自身のアドバイザリがその技術的詳細を裏付けている測定値を割り引く理由ではない。

LiteLLMの外まで伝わる記録の部分は、2つの日付の間の空白です。その脆弱性は春にクローズされました。第三者がその脆弱性の影響を受けることにつながるデフォルト設定は、9月の時点でもインストール手順に依然として記載されており、ソフトウェアがそれを拒否するようになったのは10月になってからでした。文字列を変更した運用者たちは、そうしたことを待つ必要は一切ありませんでした。