CVE-2026-42208：LiteLLM SQLインジェクション脆弱性の実態と対策
企業が生成 AI を業務に組み込む速度が上がるほど、LLM（大規模言語モデル）への入り口を束ねる「中継地点」が攻撃者の新しい標的になる。CVE-2026-42208 は、その中継地点に位置する OSS ライブラリ LiteLLM に発見された SQL インジェクション脆弱性であり、米国 CISA KEV（米国サイバーセキュリティ・インフラセキュリティ庁が悪用確認済み脆弱性をまとめるカタログ）への登録が示すとおり、すでに実環境での悪用が確認されている。AI 投資を加速させている企業ほど、この中継地点を見直す必要がある。
脆弱性の概要 — CVE-2026-42208 とは何か
LiteLLM は、OpenAI・Anthropic・Google Gemini・Azure OpenAI など複数の LLM プロバイダーへのアクセスを一元管理するオープンソースの LLM プロキシ（複数の AI サービスへのリクエストを受け取り、適切な宛先に転送する中継ソフトウェア）である。社内 ChatGPT クライアントや RAG（Retrieval-Augmented Generation / 社内ドキュメントを検索しながら AI に回答させる手法）基盤、MLOps（機械学習モデルの開発・運用を効率化する一連の仕組み）の中核に採用している企業が増えており、認証情報とアクセスログが集中する構造上、侵害時の影響範囲が広い。本脆弱性は SQL インジェクション（SQLi / データベースへの問い合わせ文に攻撃用文字列を埋め込み、本来参照できないデータを読み出させたり改ざんさせる古典的な攻撃手法）に分類される。CISA KEV への登録は「概念実証段階ではなく、実際の攻撃での利用が確認された」ことを意味し、対応の緊急度が定義上引き上げられる。出典: NVD（https://nvd.nist.gov/vuln/detail/CVE-2026-42208）。
攻撃シナリオ — 何が起きうるか
侵害は主に 3 段階で進行する。第一段階として、攻撃者は LiteLLM の公開エンドポイント（外部からアクセス可能な API の受け口）に対し、SQL インジェクション用の細工を施したリクエストを送信する。LiteLLM が内部で利用する管理データベースのクエリ（問い合わせ文）に攻撃文字列が混入し、認証を迂回した形でデータベースの内容が返却される。第二段階では、プロキシ管理 DB に保存された OpenAI・Anthropic・Gemini 等の API キー（各 LLM サービスへのアクセス権を示す秘密鍵）や社員のプロンプト（AI への入力文）履歴、利用統計が一括抽出される。第三段階において、攻撃者は抽出した API キーを自前の環境から使い始め、被害企業のクラウド請求が急騰する。同時に、社員のプロンプト履歴を分析した BEC（ビジネスメール詐欺 / 幹部や取引先を装って送金や情報提供を誘導する詐欺手法）の足場に転用されるリスクもある。この事例が示すのは、攻撃者の主目的が「AI モデルを破壊する」から「AI の利用権限ごと盗む」段階に移行しつつあるという構造的変化である。
影響範囲 — 誰が・どこまで露出するか
影響を受けるのは LiteLLM v1.x の特定バージョン範囲を稼働させている環境全般である。具体的には、① 社内 ChatGPT クライアントのバックエンドとして導入しているケース、② 社内ナレッジベースや契約書・設計書を検索させる RAG（Retrieval-Augmented Generation / 社内データを参照しながら AI に回答させる仕組み）基盤、③ CI/CD パイプライン（ソフトウェアのビルドからデプロイまでを自動化する仕組み）に組み込んだ AI モデル切替プロキシ、④ MLOps ダッシュボードで複数モデルの利用統計を集計している環境、が該当する。注意すべきは、「VPN（社内専用のプライベートネットワーク）内部にあるから外部からは触れない」という思い込みでは対策が不十分な点だ。社内ネットワークに侵入済みの攻撃者や、内部からの誤操作・悪意ある行為者が同様の手口を使えるためである。公開エンドポイントの有無にかかわらず、バージョン確認を優先したい。
なぜ LiteLLM が狙われたのか — AI プロキシ層という新しい攻撃面
2024 年までのセキュリティ議論は、LLM モデル本体への敵対的プロンプト（AI の動作を意図的に歪める入力）や学習データの汚染、プロンプトインジェクション（入力文に悪意ある命令を埋め込む手法）に集中していた。2025 年以降、管理層・プロキシ層が新しい攻撃面として浮上した理由は三点ある。第一に、複数の LLM を用途別に使い分ける企業が増え、コスト管理・認証の一元化を目的として「中継地点」を集約する需要が高まった。第二に、その中継地点が各プロバイダーの API キー（アクセス認証鍵）を束ねる「鍵束」として機能しており、侵害一点突破で全プロバイダーへのアクセス権を失う構造になっている。第三に、LiteLLM はオープンソース由来であり、「無償で使えるツール」として現場が独自導入するケースが多く、情シスによるセキュリティレビューが薄いまま本番稼働に至りやすい。AI 基盤の急所は、高度なモデル本体ではなく、それを束ねる管理ハブに移っている。
検出方法 — 自社が脆弱か 30 分で見分ける
まず ① 稼働中の LiteLLM バージョンを litellm --version コマンドで確認し、脆弱なバージョン範囲に該当するかを NVD の CVE-2026-42208 ページで照合する。次に ② DB エンドポイント（データベースへの接続口）および管理 UI が外部から到達可能かを、Nmap（ネットワークスキャンツール）や Shodan（インターネットに公開されたデバイスを検索できるサービス）を使って確認する。③ 過去 90 日のアクセスログから、異常な SQL クエリパターンや大量の認証情報読み出しを grep（テキスト検索コマンド）で抽出する。④ 各 LLM プロバイダーの課金ダッシュボードで前月比 5 倍以上の API コール増がないかを確認する。⑤ LiteLLM の管理画面および接続先クラウドアカウントに見覚えのない管理者アカウントが追加されていないかを点検する。
暫定対応 — 24-72 時間でやる 4 つ
- LiteLLM の管理 UI（運用管理画面）および DB エンドポイント（データベースへの接続口）への外部アクセスを、VPN（社内専用のプライベートネットワーク）内部かつ IP 許可リストに限定し、インターネット側からの到達経路を即時遮断する
- OpenAI・Anthropic・Google Gemini・Azure OpenAI を含むすべての LLM プロバイダーの API キー（各サービスへのアクセス認証鍵）を即時ローテーション（無効化と再発行）し、旧キーが残っていないかリポジトリや環境変数ファイルを点検する
- WAF（Web Application Firewall / Web 通信をリアルタイムで解析し、攻撃パターンに合致するリクエストを遮断する仕組み）の SQLi シグネチャ（攻撃パターンの定義ファイル）を最大強度に設定し、LiteLLM のエンドポイントを監視対象に追加する
- 過去 90 日分のアクセスログ・課金履歴・管理者アカウント一覧をイミュータブルストレージ（書き換え不可の保存領域）に保全する。後の監査やインシデント対応（侵害発生時の調査・復旧活動）で証拠として必要になる
恒久対応 — 30 日でやる 4 つ
- LiteLLM を CVE-2026-42208 の修正コミットを含むパッチ済みバージョンに更新する。NVD および LiteLLM 公式リリースノートで修正バージョン番号を確認してから適用すること
- API キーを Vault（HashiCorp Vault・AWS Secrets Manager・Azure Key Vault 等の集中シークレット管理ツール / 秘密情報を暗号化して一元管理し、アクセス履歴を記録する仕組み）に集約し、LiteLLM からは有効期限付きの短命トークン経由でのみ参照させる設計に変更する
- AI プロキシ層全体を Zero Trust ネットワーク（社内・外部を問わずすべてのアクセスを個別に認証・認可する設計思想）に組み込み、「VPN 内部であれば信頼できる」という前提を排除する。各コンポーネント間の通信にも最小権限の認証を要求する
- LiteLLM 由来の API 課金異常を AWS Cost Anomaly Detection や CloudWatch アラートに組み込み、月次から日次の異常監視へ移行する。しきい値は「前日比 300% 超」を起点に自社のベースライン使用量に合わせて調整する
AI 基盤の急所は本体ではなく、中継地点に集まる。
経営者が問うべき 3 つの質問
- 自社の AI 基盤に LiteLLM があるか、誰が把握しているか — オープンソースのプロキシは現場エンジニアが独自導入しやすく、情シス（情報システム部門）の管理台帳に記載されていないケースが目立つ。「使っているかどうか 24 時間以内に答えられない」状態は、AI 基盤ガバナンスが現場任せになっているサインである
- LLM プロバイダーの API キーは誰が・どこに保管しているか — 平文の .env ファイル（環境変数の設定ファイル）、コードリポジトリ、共有 Excel に転がっていないか。キーの保管場所と発行者のリストを情シスが即座に提示できるかが管理水準の指標になる
- クラウド請求書の異常検知は週次か日次か — 攻撃者が API キーを悪用した場合、72 時間以内に数千万円規模の請求が積み上がりうる。週次レビューでは発見が遅れる。日次の自動アラートが最低水準として求められる
Omamori AI の結論
- 事実: CVE-2026-42208 は、AI 基盤の「中継地点」が独立した攻撃面として成立したことを示す象徴的な事例である。CISA KEV（米国 CISA の悪用確認済み脆弱性カタログ）に登録済みであり、概念実証段階を超えた実害が確認されている
- 判断軸: 自社の AI 基盤に LiteLLM が含まれているかを 24 時間以内に把握できない組織は、AI 基盤ガバナンスが現場任せになっている状態と判断できる。技術的負債の問題ではなく、管理体制の問題として経営課題に位置付ける必要がある
- 打ち手: ① 暫定対応 4 点を 72 時間以内に完了、② 恒久対応 4 点を 30 日以内に実装、③ AI 基盤コンポーネント台帳に「プロキシ・管理層」カテゴリを新設し、含まれるすべての OSS ライブラリとバージョンを記録した上で四半期レビューを開始する
経営者視点で考えるべきこと
第一に善管注意義務の観点がある。CISA KEV への登録は米連邦機関に対して 7 日以内の対応を義務付ける基準であり、日本企業においても「カタログの存在を知らなかった」という説明は、取締役会や監査法人に対して通りにくくなっている。第二に連鎖被害のリスクがある。API キーの流出は単独では終わらず、クラウド請求の急騰・社員プロンプト履歴の漏洩・社内データへのアクセスという三つの被害が同時に発生しうる。このパターンはサイバー保険（サイバー攻撃による損害を補償する保険商品）の補償範囲外と判定されやすく、全額自己負担になるリスクがある。第三にオープンソース依存リスクがある。「無償で使えるライブラリ」は調達 DD（デューデリジェンス / 導入前のリスク評価と精査）が適用されにくく、現場主導で本番環境に組み込まれた後に管理の空白が生まれる構造的問題を持つ。第四に AI 投資配分の見直しである。モデル開発やプロンプト最適化への投資が先行する一方、中継地点を管理する仕組みへの投資は限界収益が高い段階にある。来期予算において、AI 基盤コンポーネント台帳の作成とその四半期レビュー体制の整備を、経営層が明示的に承認する形で盛り込むことを推奨する。
