2026年5月8日、米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は、AIゲートウェイ「LiteLLM Proxy」のSQL注入脆弱性CVE-2026-42208をKnown Exploited Vulnerabilities（KEV）カタログに追加し、米国連邦民間行政機関(FCEB agencies)に対して2026年5月11日までのremediationを求めました。本脆弱性はGitHub Security Advisoryで CVSS v4 9.3（Critical）、NVDでは CVSS v3.1 9.8（Critical）と評価されており、認証なしの状態でLiteLLM ProxyのバックエンドPostgreSQLデータベースに対して任意のSELECT文を実行できる事前認証SQL注入です。攻撃が成功すると、LiteLLM内に保存されているOpenAI・Anthropic・AWS Bedrock等のLLMプロバイダAPIキー、組織のクレジット情報、仮想キー（Virtual Keys）、チーム設定、予算上限といった、いわゆる「クラウドアカウント侵害級」の機密情報が流出する可能性があります。
本記事は、TKC Tech Labで継続して追跡しているAIエージェント脆弱性シリーズ（OpenClaw、Flowise、Marimo、nginx-ui、Cohere Terrarium）の7本目に位置付けられます。今回特筆すべきは、GitHub Advisory Database公開から約36時間で実環境での悪用が観測されたという速度感です。LiteLLM公式は、修正を安定版に取り込んだうえでGHSAを公開したと説明しており、防御運用上は「アドバイザリ可視化から攻撃開始まで」の時間軸が極めて短かった事例として位置付けられます。LiteLLMが先月にもTeamPCPによるサプライチェーン攻撃の標的になっていたという文脈も踏まえると、AIエージェント実行基盤のセキュリティ運用が、もはや「あって当然」の段階を超えて「他のクラウドサービスと同水準のIRサイクル」が必要な段階に来ていることを示す事例と言えます。
脆弱性の概要
CVE-2026-42208は、BerriAI社が開発しているLiteLLM Proxyにおける事前認証SQL注入脆弱性です。LiteLLMは、複数のLLMプロバイダAPI（OpenAI、Anthropic、Azure OpenAI、AWS Bedrock等）を統一インタフェースで利用するための、広く使われるオープンソースAIゲートウェイです。企業のAIエージェント実行基盤として採用されているケースも増えています。
影響を受けるバージョンは、LiteLLM Proxy v1.81.16〜v1.83.6です。修正版はv1.83.7、LiteLLM公式は安定版としてv1.83.10-stableへのアップグレードを推奨しています。LiteLLM公式ブログによれば、本脆弱性はバグバウンティプログラム経由での報告を受け、修正後にGitHub Security Advisoryとして公開されました。GitHub Advisory Databaseへの公開は2026年4月24日16:17 UTCで、CVE採番（CVE-2026-42208）はその後に行われています。
根本原因は、LiteLLM ProxyがクライアントからのAPIキー検証処理を実装する際の典型的な実装ミスです。LiteLLM公式ブログの説明を引用すると、「プロキシAPIキー検証時に使用されるデータベースクエリが、呼び出し側から渡されたキー値をパラメータとして渡すのではなく、クエリテキストに直接連結していた」状態でした。具体的には、HTTPリクエストのAuthorization: Bearerヘッダー値を、PostgreSQLクエリ文字列にそのまま埋め込む実装になっていたため、攻撃者はsk-litellm'のように単一引用符を含む値を送り込むことで、SQLインジェクションを成立させることができました。
攻撃手法の技術詳細
Bishop Fox社の解析によれば、本脆弱性は/v1/chat/completions、/v1/completions、/v1/messages、/v1/embeddingsといったLLM API互換エンドポイントすべてから到達可能です。これらは認証チェックの前段でAuthorization: Bearerヘッダーを処理する設計のため、攻撃者は認証情報を一切持たなくても脆弱性をトリガーできます。
Bishop Foxは、自分たちの再現環境で本脆弱性を検証しています。応答が常にHTTP 401（固定のJSONエラーボディ）を返すため、エラーベース手法やUNIONベース手法では成功確認ができないという前提のもと、PostgreSQLのpg_sleep()関数を悪用したtime-based blind SQL injectionで脆弱性の再現を実証しました。応答時間の差分から情報を抽出する手法です。
影響の重大さを大きく押し上げる要因として、Bishop Foxは「Docker Compose標準デプロイメント」の構成上の問題を指摘しています。BerriAI公式のDocker compose設定で、デフォルトのPostgresイメージをサイドカーとして起動した場合、LiteLLMアプリケーションユーザーがDBスーパーユーザー権限を持つ状態になるとされています。これにより、本脆弱性の影響は「機密メタデータの読み取り」レベルから「LiteLLMが管理する全テーブルに対する読み書き権限」レベルへと跳ね上がります。読み書き対象となるテーブルには、有効な仮想キー（Virtual Keys）、チームバインディング、予算上限、認証情報を保持するLiteLLM_VerificationTokenとLiteLLM_Credentials等が含まれます。
被害想定——クラウドアカウント侵害級の流出
本脆弱性が深刻と評価される最大の理由は、LiteLLMが管理しているデータの性質です。Sysdigが指摘しているように、典型的なLiteLLM環境ではlitellm_credentialsテーブルの1レコードに「月額5桁の支出上限を持つOpenAI組織キー」「ワークスペース管理者権限を持つAnthropicコンソールキー」「AWS Bedrock IAM認証情報」といった、それぞれ単独でも組織のクラウドコストやデータアクセスに直結する高権限の認証情報が並んで保管されています。
このため、Sysdigは「成功したデータベース抽出の影響範囲は、典型的なWebアプリケーションSQL注入というより、クラウドアカウント侵害に近い」と評しています。実際の悪用シナリオとしては、(1)LiteLLM環境からOpenAIキーを盗み出して別組織のLLM呼び出しを大量実行（金銭的損害）、(2)Anthropicワークスペース管理者キーを使った機密プロンプト・データ閲覧（機密情報流出）、(3)AWS Bedrock IAMキーを使ったクラウドリソースアクセス（さらなる横展開）など、複数の重大シナリオが想定されます。
Sysdig観測レポートによれば、攻撃者はBishop Foxの再現環境とは異なり、より直接的な手法を取っていました。実観測ではUNION SELECTを用いたスキーマ列挙とデータ抽出試行が確認されており、column-count discoveryののち、応答ボディにデータを乗せて返す抽出手法が用いられていたとされます。具体的に観測されたSQL文は、UNION SELECTでlitellm_verificationtoken、"LiteLLM_VerificationToken"、litellm_credentials、およびlitellm_configのうちparam_name='environment_variables'を満たすレコードを抽出するものでした。最後のenvironment_variables抽出は、LiteLLM設定に記載された環境変数（しばしばAPIキー類が含まれる）を狙ったものと考えられます。再現側と実観測側で手法が異なっていたことは、防御運用上「想定攻撃手法を一つに絞らない」必要性を示しています。
悪用の速度——アドバイザリ公開から36時間後にin-the-wild観測
本脆弱性のタイムラインで特筆すべきは、アドバイザリ公開から悪用までの速度です。LiteLLM側の修正コミットは2026年4月19日、修正を安定版に取り込んだうえでGitHub Advisory Database公開は4月24日16:17 UTCに行われました。そしてSysdigによれば、Advisory公開から約36時間後（2026年4月26日04:24 UTC）に、実環境における最初のSQL注入試行が観測されたとされています。
Sysdig観測の興味深い点として、攻撃者は2つのIPアドレス（隣接する/22ブロック内、同一の自律システム）から、同一のUser-Agent「Python/3.12 aiohttp/3.9.1」を用いて20分間隔でリクエストを送出しています。Sysdigはこれを「複数の独立した攻撃者ではなく、単一のオペレータが2つのIPを切り替えて使っている」パターンとして整理しています。攻撃者がCVE採番前のGHSA公開段階でアドバイザリを監視し、即座に攻撃インフラを準備していたことを示唆します。
Sysdigは重要な指摘として、「CVEベースのアラート機能やCISA KEVカタログ取り込みに依存している防御者は、このアドバイザリを適切なタイミングで検知できなかった」と述べています。攻撃が観測された時点で本脆弱性はCVEがまだ採番されておらず、CISA KEV登録もされていなかったためです。GitHub Advisory（GHSA）レベルでの監視と即応が必要だった事例として、防御運用の見直しを促す内容です。
CISA KEV登録と5/11パッチ期限
CISAは2026年5月8日、本脆弱性をKnown Exploited Vulnerabilities（KEV）カタログに追加しました。Binding Operational Directive（BOD）22-01に基づき、米国連邦民間行政機関（FCEB agencies）に対して2026年5月11日までのremediationを義務付けています。脆弱性公開（4月24日）から実質2週間強、CISA KEV追加から3日という極めて短い期限です。
BOD 22-01は連邦機関を直接の対象とする規則ですが、Copy Fail（CVE-2026-31431）の事例と同様、米国連邦と取引のある企業や、規制業界の組織にとっては事実上の業界標準として機能してきました。日本国内の組織であっても、米国子会社・グループ会社や米国顧客を持つ事業者は、5月11日を念頭に置いた対応計画を立てることが推奨されます。
AIエージェント脆弱性シリーズとしての位置づけ
本件は、TKC Tech Labで継続追跡しているAIエージェント脆弱性シリーズの直近事例として、いくつかの示唆を含んでいます。記事#29 OpenClaw（CVE-2026-33579）、記事#30 Flowise（CVE-2025-59528）、記事#34 Marimo（CVE-2026-39987）、記事#37 nginx-ui（CVE-2026-33032）、記事#40 Cohere Terrarium（CVE-2026-5752）と続いてきた一連の脆弱性は、いずれも「AI開発・運用基盤の中核コンポーネントが、従来のWebアプリケーションと比較して未成熟なセキュリティ実装を抱えている」という共通構造を持っています。
とりわけLiteLLMの場合、先月（2026年4月）にTeamPCPによるサプライチェーン攻撃の標的になり、ダウンストリームユーザーから認証情報・シークレットを窃取する目的で改ざんが試みられた前例があります（TKC Tech Lab記事#21 Trivyサプライチェーン攻撃の続報シリーズ）。今回のCVE-2026-42208は、サプライチェーン経由ではなく、デプロイ済みLiteLLM Proxyへの直接攻撃という別のベクトルですが、攻撃者の関心が一貫してLiteLLM等のAIゲートウェイに集中していることを示しています。
共通する構造的問題は、AIゲートウェイが「複数のLLMプロバイダ認証情報を一元管理する」という性質上、侵害された場合の被害が広範囲に及ぶことです。OpenAI・Anthropic・Azure OpenAI・AWS Bedrockといった各プロバイダの認証情報を1つの場所に集約することは、運用効率の観点では合理的ですが、セキュリティ観点では「単一障害点（SPoF）」を作り出します。AIゲートウェイ層のセキュリティハードニングは、もはや「便利な追加機能」ではなく「導入の前提条件」として位置付けるべき段階に来ています。
パッチ適用と侵害指標（IoC）
対応の基本方針は、LiteLLM Proxyを直ちにv1.83.7以降（推奨：v1.83.10-stable）にアップグレードすることです。バージョン確認はpip show litellmまたはlitellm --versionで実施できます。Docker環境ではイメージタグ確認後、docker compose pullと再起動が必要です。
パッチ適用前の暫定対策として、LiteLLM Proxyのインターネット公開を停止する、リバースプロキシ層でのIP制限を強化する、Web Application Firewall（WAF）でAuthorization HTTPヘッダー内の異常パターン（単一引用符、UNION SELECT、pg_sleep等）を遮断する、といった多層防御が有効です。
侵害確認のためのIoC（Indicators of Compromise）として、Sysdigレポートで観測された具体的な指標を整理します。
- HTTPリクエスト：
POST /chat/completionsまたはPOST /v1/chat/completions - リクエストボディ：空、または75バイト
- User-Agentヘッダー：
Python/3.12 aiohttp/3.9.1（攻撃キャンペーン時点での観測値） - Authorizationヘッダー値：
sk-litellm'（単一引用符を含む）から始まる値 - ヘッダー値内に含まれるSQL断片：
UNION SELECT、FROM litellm_verificationtoken、FROM "LiteLLM_VerificationToken"、FROM litellm_credentials、FROM litellm_config WHERE param_name='environment_variables'
パッチ適用済みの環境であっても、影響期間中に攻撃を受けた可能性がある場合は、侵害想定での対応が必要です。具体的には、(1)LiteLLM内に保存されているすべてのAPIキー（OpenAI、Anthropic、AWS Bedrock、その他LLMプロバイダ）のローテーション、(2)LiteLLM管理者キーおよび仮想キーのローテーション、(3)PostgreSQLデータベース内データの整合性確認、(4)ログにおける異常アクセスの遡及確認、が推奨されます。
実務観点での要点
CVE-2026-42208が示す実務的な論点は、以下の3点に集約されます。
1つ目は、AIエージェント実行基盤のセキュリティ成熟度の現状です。LiteLLMは広く使われているOSSですが、API key検証という最も基本的な経路に古典的なSQL注入パターンが残存していました。本件は単独の事例ではなく、AIゲートウェイ・AIエージェントビルダー・LLMコード実行環境といった「AI関連の新興インフラコンポーネント」全般で同種の問題が継続的に発覚している傾向の一部として捉えるべきです。
2つ目は、CVE採番前の脆弱性監視の必要性です。Sysdigが指摘した通り、攻撃者はGHSA公開段階で攻撃を開始しており、CVE採番やCISA KEV登録を待つ防御運用では間に合いませんでした。GitHub Security Advisory、PyPI/npm等のパッケージレポジトリのアラート、Dependabot通知、SCA（Software Composition Analysis）ツールの早期取り込みなど、CVE非依存の脆弱性検知経路を整備することが、AIインフラ運用では特に重要になります。
3つ目は、認証情報集約のリスク管理です。AIゲートウェイは複数のLLMプロバイダ認証情報を1か所に集約する設計上、侵害された場合の被害範囲が広範になります。AIゲートウェイ自体のセキュリティハードニング（パッチ管理、最小権限のDB構成、ネットワーク分離、シークレット管理の外部化等）に加え、APIキーのローテーション運用、利用上限の細分化、異常検知の組み込みといった多層的な対応設計が、AI関連プロジェクトの初期段階から必要となります。
ソース
一次情報
- LiteLLM公式ブログ：「Security Update: CVE-2026-42208 in LiteLLM Proxy」（
https://docs.litellm.ai/blog/cve-2026-42208-litellm-proxy-sql-injection） - GitHub Security Advisory：GHSA-r75f-5x8p-qvmc
- Bishop Fox: 「CVE-2026-42208: Pre-Authentication SQL Injection in LiteLLM Proxy」
- Sysdig: 「CVE-2026-42208: Targeted SQL injection against LiteLLM’s authentication path discovered 36 hours following vulnerability disclosure」
- CISA Known Exploited Vulnerabilities Catalog（CVE-2026-42208エントリ、2026年5月8日追加）
- NVD:
https://nvd.nist.gov/vuln/detail/CVE-2026-42208
参考情報
- The Hacker News: 「LiteLLM CVE-2026-42208 SQL Injection Exploited within 36 Hours of Disclosure」
- cybersecurefox.com: 「Critical LiteLLM Vulnerability CVE-2026-42208: SQL Injection In AI Gateway Under Active Exploitation」
- cve.news: 「CVE-2026-42208 – Critical LiteLLM SQL Injection Risk Exposes Secrets and Access」
※本稿の内容は公開時点で確認できた情報に基づきます。CISA KEVカタログ、LiteLLM公式アドバイザリ、各種一次情報は更新されるため、最新情報は各公式ページでご確認ください。
slug: litellm-cve-2026-42208-cisa-kev-may11
コメント