CISA KEVに追加されたLiteLLMのSQL Injection脆弱性について、対象バージョン、影響範囲、APIキー確認、更新・ローテーションの初動を整理する。
何が起きたか
2026年5月8日、CISA の Known Exploited Vulnerabilities（KEV）カタログに BerriAI LiteLLM の SQL Injection 脆弱性 CVE-2026-42208 が追加された。GitHub Advisory と NVD の情報では、影響を受けるのは LiteLLM 1.81.16 以上 1.83.7 未満で、修正版は 1.83.7 とされている。
LiteLLM は、複数の LLM API を OpenAI 互換の形式で扱うための AI Gateway / プロキシとして使われることが多い。ここで重要なのは、脆弱性の名前そのものよりも、プロキシが保持するAPIキー、プロキシDB、利用ログが同じ場所に集まりやすいという運用上の影響だ。
現時点で公開情報から確認できる範囲では、CISA KEV ではランサムウェアキャンペーンでの利用は Unknown とされている。したがって「大規模悪用が確認された」とは書かない。一方で KEV 掲載は、すでに悪用が確認された脆弱性として扱うべき強いシグナルであり、AI基盤を運用している組織は自社影響の確認を急ぐ必要がある。
影響を受ける可能性がある組織・担当者
まず確認したいのは、LiteLLM を直接導入しているかどうかだけではない。AI Gateway を検証環境、社内向けPoC、開発者向け共通プロキシとして立てている場合、正式な本番システムより台帳管理が弱いことがある。
特に影響確認の対象になりやすいのは次の担当者だ。
- LiteLLM や独自 AI Gateway を運用している開発基盤チーム
- OpenAI、Azure OpenAI、Anthropic、Google など複数の LLM API キーを集約しているSRE
- 社内チャットボット、問い合わせ補助、コードレビュー補助などをAIプロキシ経由で提供している情シス
- プロキシDBやログにプロンプト、ユーザーID、利用量、APIキー情報が残る構成を管理しているセキュリティ担当
「AIツールは検証用途だから後回し」と判断すると、APIキーやログの扱いを見落とす。検証環境でも有効なAPIキーを持っているなら、脆弱性対応の対象に入れるべきだ。
なぜ重要か
GitHub Advisory は、この脆弱性によりプロキシのデータベース内の情報を読まれたり変更されたりする可能性があると説明している。NVD では CVSS v4.0 のスコアが 9.3 Critical、CVSS v3.1 の基本値が 9.8 Critical と表示されている。
ただし、実務上の判断はスコアだけでは足りない。AI Gateway では、次のような情報が同じ運用面に集まりやすい。
| 確認対象 | 見落とした場合の影響 |
|---|---|
| LLM APIキー | 不正利用、過剰課金、接続先サービスへの影響 |
| プロキシDB | ユーザー、モデル設定、キー管理情報の改ざん・閲覧 |
| 利用ログ | プロンプト、内部情報、顧客情報の露出 |
| 管理者設定 | ルーティング、レート制限、アクセス制御の変更 |
つまり、このCVEは「ライブラリを更新して終わり」ではない。更新前後で、資格情報とログの扱いまで確認する必要がある。
まず確認すべきこと
初動は、攻撃再現ではなく、資産と設定の確認から始める。
- LiteLLM または LiteLLM を含む AI Gateway を利用しているか確認する。
- 対象バージョンが
1.81.16以上1.83.7未満に該当するか確認する。 - プロキシがインターネット公開、社内限定、CI/CD限定、検証環境のどこにあるか分類する。
- プロキシが保持する LLM API キー、管理者トークン、DB接続情報を一覧化する。
- 不審なモデル利用、リクエスト増、想定外の課金増加、プロキシDB変更がないか確認する。
- 更新、緩和策、キー失効・再発行、ログ保全の責任者を決める。
CyberLens では、この確認をそのまま作業に落とせるように AIプロキシ・LLM APIキー漏えい確認チェックリスト を追加した。CVEの一般的な初動は CVE初動対応チェックリスト も合わせて使う。
推奨される初動対応
公式情報に基づく対応の軸は、修正版への更新と、資格情報・ログの影響確認だ。
| 優先度 | 対応 | 完了条件 |
|---|---|---|
| 高 | 対象バージョンの特定 | 本番・検証・PoCを含めて対象有無をチケット化する |
| 高 | 修正版またはベンダー緩和策の適用 | 適用後のバージョンと設定を記録する |
| 高 | APIキーの失効・再発行判断 | 有効な露出疑いのあるキーを用途単位で処理する |
| 中 | プロキシDB・監査ログ確認 | 不審なユーザー、キー、設定変更の有無を記録する |
| 中 | 再発防止 | キー分離、ログマスキング、利用量アラート、発行承認を見直す |
GitHub Advisory には一時的な緩和策も記載されているが、恒久対応としては修正版への更新を優先する。パッチ適用がすぐできない場合も、外部到達制限、管理者アクセス制限、キーの権限縮小、利用量監視でリスクを下げる。
公式情報の確認先
このニュースは、次の一次情報をもとに整理した。
- CISA Known Exploited Vulnerabilities Catalog: CVE-2026-42208
- GitHub Advisory Database: GHSA-r75f-5x8p-qvmc
- BerriAI LiteLLM Security Advisory: GHSA-r75f-5x8p-qvmc
- NVD: CVE-2026-42208
最新の影響範囲や修正版は、必ずベンダー公式アドバイザリと自社の導入状況で確認してほしい。
関連する CyberLens 内部リンク
このテーマは、AI基盤だけでなく、サプライチェーンと資格情報管理の問題として見ると判断しやすい。
- AIプロキシ・LLM APIキー漏えい確認チェックリスト
- CVE初動対応チェックリスト
- GitHub secret leak対応チェックリスト
- AI開発基盤とLiteLLM周辺リスク
- SBOMとOSV-Scannerで依存関係リスクを棚卸しする実習
- KEVとは
- Secret Scanningとは
まとめ
CVE-2026-42208 は、LiteLLM を使っていない組織には直接影響しない。しかし、AI Gateway やLLMプロキシを使っている組織では、単なるパッケージ更新ではなく、APIキー、プロキシDB、ログ、利用量まで確認する必要がある。
まずは対象環境の有無を確認し、該当する場合は AIプロキシ・LLM APIキー漏えい確認チェックリスト で、更新・失効・記録の順番を揃えてほしい。AI基盤は新しいが、初動対応の基本は変わらない。対象資産、資格情報、ログ、残リスクを分けて記録することが、後日の説明責任を支える。
