CISA、LiteLLMのMCP認証バイパスをKEVに追加：任意のベアラートークンだけで十分だった

2026年9月2日、米国サイバーセキュリティ・インフラストラクチャー安全保障局はCVE-2026-59822を「BerriAI LiteLLM Improper Authentication Vulnerability」として、既知の悪用済み脆弱性カタログに追加した。これは同日のバッチに含まれる7件の脆弱性のうちの1件である。この不具合はLiteLLMのMCP Streamable HTTPエンドポイントにあり、LiteLLMキーの検証が失敗すると、OAuth2パススルーのフォールバックがリクエストを拒否する代わりに空のUserAPIKeyAuth()オブジェクトを代入したため、でっち上げのAuthorization Bearerヘッダーでも認証済みのMCPセッションが開かれてしまった。そのエンドポイントに到達した攻撃者は、ゲートウェイに構成されたすべてのMCPツールを一覧表示して呼び出すことができ、さらにそれらのツールを通じて背後にあるサービスに到達できた。1.84.0より前のすべてのバージョンが影響を受け、連邦の民間機関には9月16日までに是正するよう期限が与えられた。この記録 — LiteLLMのMCP認証バイパスに関するKEV掲載 — は、OrcaRouter AIインシデントアーカイブに収められた1エントリです。このアーカイブには、完全な記録セットとこのインシデントに隣接するエントリが収められています。

プロキシのバグがCVSSスコアから示唆される以上に重要である理由は、プロキシの背後に何があるかにある。Wizの脅威リサーチチームは次のように率直に述べている。「LiteLLMプロキシは、ルーティング先のすべてのモデルプロバイダー（OpenAI、Anthropic、Azure、Geminiを含む）のキーを保持できる。また、クラウドIAM権限で動作し、MCPツールサーバー経由で内部サービスに接続する可能性もある。一度侵害されれば、攻撃者はプロキシ自体だけでなく、プロキシの下流にある認証情報やサービスにもアクセスできる。」Wiz Researchはこの欠陥を発見したと述べており、その後Wizのハニーポットはそれを利用しようとする試みを記録した。

仕組み：失敗したチェックが有効なセッションを返した

BerriAI自身のアドバイザリGHSA-7488-6r32-c95qは、この欠陥を2文で説明している。「MCP認証ハンドラーは上流のMCPサーバーへのOAuth2パススルーをサポートしていたが、フォールバック経路では、失敗したLiteLLMキー検証を空のUserAPIKeyAuth()オブジェクトで置き換える可能性があった。これにより、偽造されたAuthorizationヘッダーを持つリクエストが、有効なLiteLLMキーなしでMCPツールに到達できるようになった」。重要な言葉はフォールバックだ。コードには、上流MCPサーバーのOAuthトークンをそのまま通すデプロイ向けの分岐があり、LiteLLMキーの検証に失敗すると、その分岐はエラーではなく空の認証オブジェクトを返していた。

空の認証オブジェクトは、認証オブジェクトが存在しないこととは同じではありません。下流のコードは、正常に構築された UserAPIKeyAuth を目にしてそのまま処理を進めましたが、そこにはテナントもユーザーもスコープも付与されていませんでした。Wiz の解説は、実際の影響についてより率直に述べています。「トークンの検証が失敗した場合、サーバーはリクエストを拒否するのではなく、制限の一切ない空の UserAPIKeyAuth() オブジェクトを返します。任意の Bearer トークン（たとえ 1 文字だけの x であっても）が MCP への完全なアクセスを許可してしまいます。」

攻撃者がこれによって手に入れるのは、メニューです。MCPプロトコルはツール一覧を公開するため、認証されたセッションは、ゲートウェイが接続できるよう設定されているすべてのツールの名前とスキーマを返します。Wizの例では、データベース、コードリポジトリ、内部APIなどです。ベンダーのアドバイザリはその影響を端的に述べています。「攻撃者はこれを使って、設定済みのMCPツールを一覧表示して呼び出し、MCP経由で公開されている接続済みサービスにアクセスできる可能性があります」。その後、ツール呼び出しは、プロキシ自体がそれらバックエンドに対して持つ権限で実行されます。これがWizの説明する認証情報の集中問題です。

5月に修正、7月にCVE、9月に連邦政府の期限

日付は読者が想定するようには一致しておらず、興味深いのはその間隔だ。LiteLLM 1.84.0——アドバイザリが修正済みとする最初のバージョン——は、パッケージインデックス自体のリリースメタデータによると、2026年5月14日にPyPIへアップロードされた。CVE識別子は2026年7月7日にCVEプログラムで予約され、記録は翌日である7月8日に公開された。OSVのエントリPYSEC-2026-3479は7月23日に続いた。KEVへの掲載は9月2日で、修復期限は9月16日だった。

ここから二つのことが言える。第一に、修正済みビルドは、CISAがこの脆弱性を悪用済みとしてリストに掲載するより3か月以上前から公開されていた。つまり、期限の対象となった組織には、その間ずっと有効なアップグレードが利用可能であり、KEVへの追加は修正が登場した瞬間ではなかった。第二に、その後バージョン差はさらに広がっている。PyPI上の現在のLiteLLMリリースは、2026年10月27日にアップロードされた1.106.5である。1.84.0未満のままのデプロイは今や、単に1つのパッチが不足しているだけでなく、20以上のマイナーリリース分遅れている。

そのリストが証明していること、そして証明していないこと

CISAによるこのバッチに関する警告では、追加は「活発な悪用の証拠に基づいて」行われたとされており、カタログのCVE-2026-59822に関する機械可読エントリには、追加日2026年9月2日、期限日2026年9月16日、既知のランサムウェアキャンペーンでの使用状況「Unknown（不明）」、および2つの脆弱性、CWE-287（不適切な認証）とCWE-306（重要な機能における認証の欠如）が記載されている。

• 確定:CISAはこの脆弱性を実際に悪用されていると評価し、連邦政府の修復リストに掲載した。CISAコーディネーターによるものとされ、2026年9月2日のタイムスタンプが付されたNVDのSSVCレコードでは、悪用状況が「active」、自動化可能が「yes」、技術的影響が「partial」と記録されている。

• 確認済み：管理された環境において悪用が確認された。Wizはハニーポットのトラフィックを公開し、1文字のトークンを含むリクエストがモデル列挙エンドポイントを探査していたことを示した。具体的には、"Authorization: Bearer x" を付けた /v1/models への GET リクエストである。The Hacker Newsは、9月3日のKEVバッチを報じる中で、同じ活動について、Wizが「自社のハニーポットに対してCVE-2026-59822を悪用し、モデル列挙エンドポイントを探査する試み」を観測したと説明した。

• 確定: 深刻度スコアはどちらも存在し、フレームワークによって異なります。BerriAIのアドバイザリでは、この脆弱性をCVSS 4.0で8.8（高）と評価しており、機密性は高、完全性は低、可用性はなしとしています。一方、NVDで主要な評価であるNIST独自のCVSS 3.1評価では8.2としています。これら2つの数値は、異なるスコアリングシステムの下で同じ欠陥を表しており、一方が他方を置き換えたかのように比較すべきではありません。

• 未確認：名前が挙がった被害者はなし。CISAの警告、BerriAIの勧告、Wizの解説記事、The Hacker Newsの報道のいずれも、この脆弱性を通じてMCPツールに到達された組織を特定しておらず、そこから認証情報やデータが持ち出されたとも報告していない。公開されている悪用の記録はハニーポットのテレメトリと連邦政府の判断であり、開示された侵害ではない。

• 立証されていない：ランサムウェアグループがそれを使用していないということ。KEVフィールドは「Unknown」と表示されており、これはCISAが割り当てる値であって、どちらの不在を示す所見ではありません。

6月の前例、そしてこれがそうではないリモートコード実行チェーン

これは2026年にKEVカタログへ登録された2件目のLiteLLMの脆弱性であり、以前の1件とは混同しやすい。CVE-2026-42271は2026年6月8日に追加され、期限は6月22日で、LiteLLMのMCPサーバーテスト用エンドポイントにおけるコマンドインジェクションである。Wizによると、これらのエンドポイントはユーザーが保存前にMCPサーバー設定をテストできるようにするもので、commandフィールドは検証なしにサブプロセス実行へ渡される。攻撃者は、commandが暗号通貨マイナーをダウンロードして実行する偽のstdioサーバー設定を送信し、テストが成功したように見えるよう、有効に見えるMCPハンドシェイクを返した。CISAの登録項目ではCWE-78とCWE-77、つまりコマンドインジェクションと引数インジェクションが挙げられており、認証ではない。

その欠陥こそが連鎖するものだ。Wizは、CVE-2026-42271が「Starletteのホストヘッダー検証バイパス（CVE-2026-48710）と連鎖させることで、完全に未認証のRCEを達成できる」と述べており、また外部の研究者がQilinランサムウェアグループをその連鎖の活発な悪用に関連付けていると述べている。CVE-2026-48710は、LiteLLMのバイパスと同じ9月2日のバッチでKEVカタログに追加され、期限も同じ9月16日であり、CISA自身のカタログ注記ではStarletteの脆弱性についてCVE-2026-42271と連鎖可能と記載されている。Qilinとの関連はその組み合わせに属する。これはCVE-2026-59822に関する知見ではなく、レビューした情報源のいずれも、そのランサムウェアグループを認証バイパスに関連付けていない。

2つのLiteLLM項目を分けているのは、ある事務的な詳細です。6月の掲載項目の必要な対応には、より古い拘束力のある運用指令であるBOD 22-01が引用されている一方、9月の掲載項目にはBOD 26-04「リスクに基づくセキュリティ更新の優先」が引用されています。CISAの警告はこの変更を説明しておらず、カタログもそれに注記していません。

その後、何が変わりましたか

修復までの道筋は短い。BerriAIのアドバイザリは1.84.0以降へのアップグレードを推奨し、すぐに移行できないチーム向けの回避策を提示している。「MCPルートを無効化するか、リバースプロキシまたはAPIゲートウェイで/mcp/および関連するMCPエンドポイントへのアクセスをブロックする」。この回避策は強引な手段であり、機能を制御下に置くのではなく取り除いてしまうが、未パッチのデプロイメントに対してベンダーが明示する唯一の緩和策である。

CISAのエントリポイント向けの「必要な措置」に関する文言は、連邦機関を同じトレードオフに立たせる。すなわち、ベンダーの指示に従い、BOD 26-04に沿って緩和策を適用するか、「緩和策が利用できない場合は製品の使用を中止する」かであり、各機関が資産のインターネット露出を評価する責任を負う。この指令は連邦の文民行政機関のみに拘束力を持ち、CISAは他の組織にも同じリスクベースの優先順位付けを採用するよう促しているが、義務付けてはいない。

ハニーポットの外にいる誰かがその期限に対応したかどうかは公開されていない。CISAもBerriAIも、何件のLiteLLMデプロイメントが露出したか、9月16日より前に何件がパッチ適用されたか、バイパスを通じて何件に到達したかについての数字を公表していない。

何が未解決のままですか

3つのギャップは、覆い隠すのではなく明言する価値がある。CVE-2026-59822を特定の侵入に結び付ける公開のインシデント報告書は存在しない。そのためKEVへの掲載は、文書化された被害者ではなく、CISAの悪用証拠とWizのハニーポット観測に基づいている。フォールバックパスがなぜそのように書かれることになったのか、また1.84.0より前にどれだけ存在していたのかについてのベンダー声明はない。アドバイザリは欠陥とその修正について述べており、その経緯については述べていない。また、このバッチの期限は一律ではなかった。9月2日に追加された7件のうち5件は9月5日の期限で、LiteLLMとStarletteの項目は9月16日だった。CISAはその理由を述べていない。

確定している事実は、スコアよりも範囲が狭く、より有用です。影響を受けたバージョンでは、Authorizationヘッダー内の1文字が、MCPエンドポイントにとって有効なキーと区別できませんでした。そして、そのような挙動を示していたバージョンは2026年5月に最新版ではなくなりました。