2026年4月24日、オープンソースAIゲートウェイであるLiteLLMにおいて、重大なSQLインジェクション脆弱性CVE-2026-42208がGitHub Advisory Databaseで公開されました。公開から36時間7分後には、すでに実際の攻撃が観測されており、AIインフラを標的とする攻撃の実行速度と深刻度を示す事例となっています。CVSS 9.3（Critical）と評価された本脆弱性は、認証を一切必要としない点が大きな特徴です。攻撃者は、/chat/completionsのような一般的なAPIエンドポイントに対して、細工されたAuthorization: Bearerヘッダーを1つ送信するだけで、LiteLLMプロキシのPostgreSQLデータベース上で任意のSQLクエリを実行できます。特に問題となるのは、LiteLLMが管理するデータベースに、OpenAI、Anthropic、AWS BedrockなどのクラウドAIプロバイダーのAPIキーやIAM認証情報が集中している点です。そのため、本脆弱性は単なるWebアプリケーションのSQLインジェクションにとどまらず、クラウドAI環境全体の侵害につながる可能性があります。
本記事では、CVE-2026-42208の技術的構造と侵害フローを分析し、外部に公開されたAIゲートウェイ資産がどのような新たな攻撃対象領域を形成するのかを考察します。
CVE-2026-42208 LiteLLM SQLインジェクション脆弱性の概要
| 項目 | 内容 |
|---|---|
| 脆弱性ID | CVE-2026-42208 |
| 影響製品 | BerriAI LiteLLM Pythonパッケージ |
| 脆弱性の種類 | SQL Injection |
| CVSSスコア | 9.3 (Critical) |
| 影響バージョン | 1.81.16以上 ～ 1.83.6以下 |
| パッチバージョン | 1.83.7-stable（2026年4月19日リリース） |
| 悪用状況 | 公開から36時間7分後に初回攻撃を観測 |
LiteLLMは、GitHubスター45,000件、フォーク7,600件を保有するオープンソースAIゲートウェイであり、開発者や企業がOpenAI、Anthropic、AWS Bedrock、Geminiなど100以上のLLMプロバイダーを、単一のOpenAI互換APIで統合管理するために活用されています。この構造上、LiteLLMは組織内のあらゆるAI認証情報が集中する単一の集約点となります。
技術的原因：エラーハンドリング経路におけるパラメータバインディングの欠落
本脆弱性は、LiteLLMプロキシにおけるAPIキー検証処理で発生します。
ユーザーがLLM APIエンドポイント（例：POST /chat/completions）を呼び出すと、プロキシはAuthorization: BearerヘッダーからAPIキーの値を抽出し、LiteLLM_VerificationTokenテーブルを参照します。本来であれば、キーの値はSQLパラメータとして分離して渡される必要がありますが、影響を受けるバージョンではBearer値がクエリ文字列に直接挿入されていました。問題となるのは、このクエリが通常の認証フローだけでなく、エラーハンドリング経路でも同様に実行される点です。つまり、無効なトークンを送信した場合でも、この経路を通じて脆弱なクエリに到達できる構造となっていました。
攻撃者は、Bearer値の中にシングルクォートを挿入するだけでSQLクエリ文字列をエスケープし、UNION SELECT構文を通じてデータベース内の任意のテーブルを参照できます。認証可否が判断される前の段階でインジェクションが実行されるため、プロキシポート（デフォルトでは4000番）にアクセス可能なHTTPクライアントであれば、追加条件なしで攻撃が成立します。
攻撃者が狙った3つのテーブル
実際に観測された攻撃は、無差別なスキャニングではありませんでした。攻撃者は、LiteLLMが内部で使用するPrisma ORMのPostgreSQL識別子のケーシングを事前に把握しており、3つの高価値テーブルのみを精密に標的としていました。
1つ目の標的であるLiteLLM_VerificationTokenには、仮想APIキーとマスターキーが保存されています。これらのキーは、窃取された直後から/chat/completionsでそのまま再利用でき、LiteLLMはデフォルトでキーを特定の送信元IPにバインドしません。
2つ目の標的であるlitellm_credentialsは、最も価値の高いテーブルです。OpenAIの組織キー、Anthropicのワークスペース管理者キー、AWS BedrockのIAM認証情報など、アップストリームLLMプロバイダーの実際の認証情報が集中しています。1つの行に複数プロバイダーの認証情報が同時に含まれるケースも一般的です。
3つ目の標的であるlitellm_configには、プロキシのランタイム環境変数と内部設定全体が保存されており、攻撃者がプロキシの運用環境全般を把握するために悪用される可能性があります。一方で、litellm_usersやlitellm_teamなどのユーザーアカウント関連テーブルは探索対象に含まれていませんでした。この点から、攻撃者が初期段階からAI認証情報のみを狙っていたことが分かります。
36時間：PoCなしでも、アドバイザリだけで十分だった
今回の事案が注目される理由は、悪用までの速度と攻撃精度が同時に確認された点にあります。脆弱性に対するパッチは、2026年4月19日時点ですでにリリースされていました。その後、4月24日16:17（UTC）にGitHub Global Advisory Databaseへアドバイザリがインデックスされ、初回攻撃はその36時間7分後となる4月26日に観測されました。攻撃者は、アドバイザリとオープンソースのスキーマ情報のみをもとに攻撃を再現しており、PoCコードの公開を待っていませんでした。LiteLLMはオープンソースプロジェクトであるため、データベーススキーマをコードベースから確認できました。これが、攻撃者が事前にテーブル構造を把握できた理由です。
LiteLLMを繰り返し狙う攻撃パターン
CVE-2026-42208は、LiteLLMを標的とした2件目の主要なセキュリティ事案です。わずか1か月前の2026年3月、TeamPCPハッキンググループは、LiteLLMのリリースパイプラインを悪用し、悪性PyPIパッケージを配布するサプライチェーン攻撃を実行しました。この攻撃により、下流ユーザーの認証情報やシークレットが窃取されました。3月のサプライチェーン攻撃が、信頼できるパッケージを汚染し、インストールされたすべてのシステムから認証情報を収集する手法だったのに対し、CVE-2026-42208は、脆弱なLiteLLMプロキシへ直接アクセスし、データベースから認証情報を抽出する手法です。経路は異なりますが、標的は同一です。AIゲートウェイが管理するクラウドプロバイダーの認証情報です。
Criminal IPで観測された外部公開LiteLLMインスタンス
CCVE-2026-42208の公開後、LiteLLM環境が外部に公開されている可能性を確認するため、Criminal IPを活用してインターネット上に公開されたLiteLLM関連資産を特定し、露出状況を分析しました。
Criminal IP 検索クエリ: title: LiteLLM
LiteLLMのWebインターフェースは、ページタイトルにサービス名を直接表示するため、単純なHTML titleベースの検索だけでも、外部からアクセス可能なインスタンスを特定できます。特にLiteLLMは、ネットワーク機器やWeb管理コンソールのようにインターネット公開を前提として設計されたシステムではなく、内部AIインフラに近い構成要素です。そのため、Criminal IPで識別されたすべてのインスタンスは、それ自体が誤った設定であり、プライベートネットワークやVPNによる保護なしにインターネットへ公開されたAIゲートウェイと見ることができます。
当該クエリを基準に、2026年4月時点で約2,000件以上の公開資産が識別されました。これは単に設定ミスが発生したシステムではなく、OpenAI、Anthropic、AWS Bedrockなどの上位LLMプロバイダーのAPIキーを含む、組織の機微なクラウド認証情報を中央で管理するAIゲートウェイプロキシです。CVE-2026-42208の文脈では、これらのインスタンスは認証なしで即時に悪用可能な攻撃対象となる可能性があります。
Criminal IP 検索クエリ: title: LiteLLM AND port: 4000
LiteLLMプロキシは、デフォルトで4000番ポート上で実行されます。これは一般的なWebサービスポートではないため、当該ポートで検出されるLiteLLMインスタンスは、意図せず外部に公開されている可能性をより強く示しています。特に、デフォルトポートで運用されているインスタンスは、開発環境またはテスト環境がインターネット上にそのまま公開されているケースである可能性があり、十分なセキュリティハードニングが適用されていない可能性が高いと考えられます。デフォルトポートで実行中のLiteLLMインスタンスのみをフィルタリングした結果、2026年4月時点で28件の資産が識別されました。全体の公開資産数と比較すると規模は小さいものの、デフォルト設定に近い状態で運用されている環境と見られる点で、セキュリティ上の重要度は高いといえます。CVE-2026-42208が公開から36時間以内に実際の攻撃で悪用された形跡が確認されている状況において、このようなデフォルト構成のインスタンスは、攻撃者にとって最も容易な侵入経路となる可能性があります。
検知されたLiteLLM資産のうち、特定の個別資産をCriminal IPで詳細分析した結果、当該資産ではHTTPS（443）ポートが外部に開放されていることが確認されました。また、4件の脆弱性とExploit DB関連項目1件もあわせて識別されており、単なるWebサービスの露出にとどまらず、既知の脆弱性または攻撃手法と関連し得る環境であることを示しています。この資産は、インターネット公開を前提として設計されたネットワーク機器やファイアウォールではなく、上位LLMプロバイダーの認証情報を保管し得るAIゲートウェイプロキシが、公開インターネット上にそのまま露出している事例です。
このようなインスタンスに対してSQLインジェクション攻撃が成功した場合、その影響は一般的なWebアプリケーション侵害の範囲にとどまりません。Sysdigが指摘しているように、LiteLLMデータベースの単一行には、月間数万ドル規模の利用上限を持つOpenAIの組織キー、ワークスペース管理者権限を持つAnthropicコンソールキー、AWS BedrockのIAM認証情報などが同時に保存されている可能性があります。したがって、攻撃が成功した場合の被害範囲は、単なるデータ流出ではなく、クラウドアカウント全体の侵害に近い水準まで拡大する可能性があります。
結論として、Criminal IPを通じて確認された約2,000件以上の外部公開LiteLLMインスタンスは、極めて高いリスクを持つ攻撃対象領域として評価されます。これは、CVE-2026-42208が認証なしで即時に悪用可能な脆弱性であるためだけではありません。LiteLLMインスタンスが公開インターネット上に存在しているという事実そのものが、組織のAIインフラ全体を危険にさらす深刻な構成ミスを意味するためです。
パッチ状況および対応方法
CCVE-2026-42208は、LiteLLM 1.83.7で修正されました。LiteLLMの公式アドバイザリでは、影響を受けるバージョンを1.81.16以上、1.83.7未満と明記しており、1.83.7以上へのアップグレードを案内しています。また、LiteLLMは最新の安定版である1.83.10-stableへの更新を推奨しています。
具体的には、組織は以下の対応を優先的に実施する必要があります。
- LiteLLM Proxyを1.83.7以上、可能であれば1.83.10-stableへアップデート
- 外部からアクセス可能なLiteLLM Proxy資産の特定
- /chat/completionsなど、LLM APIルートに対する外部アクセス制御
- LiteLLMデータベースのアクセスログおよびPostgreSQLクエリ履歴の確認
- litellm_credentials、litellm_configに関連する異常な参照痕跡の確認
- LLM Provider APIキー、仮想APIキー、クラウド認証情報のローテーション
- 不審IPとの通信ログの確認
特に、LiteLLM Proxyがインターネットから直接アクセス可能な状態で運用されていた場合、単にパッチを適用するだけでは十分ではありません。攻撃者が実際にデータベースを参照した可能性を考慮し、保存されていたProvider認証情報やAPIキーをすべて信頼できない状態と見なし、交換する必要があります。
FAQ
Q1. CVE-2026-42208はなぜ危険なのですか？
この脆弱性は、認証前の段階で悪用可能なSQLインジェクションです。攻撃者は有効なAPIキーを持っていなくても、細工されたAuthorizationヘッダーを送信することで、LiteLLM ProxyのAPIキー検証経路を操作できます。特にLiteLLMは、複数のLLM ProviderキーやクラウドAIサービスの認証情報を中央で管理するため、データベースの侵害がそのままProviderアカウントの侵害につながる可能性がある点で危険です。
Q2. 今回の攻撃は、従来のSQLインジェクションと何が異なりますか？
実際に観測された攻撃は、SQLmapなどの一般的な自動化スキャナーを使用した無差別攻撃ではありませんでした。攻撃者はLiteLLM内部のデータベーススキーマを事前に把握しており、数十個のテーブルのうち、AI認証情報が保存された3つのテーブルのみを精密に標的としていました。PoCが公開される前に、オープンソースのコードベースとアドバイザリだけをもとに攻撃を再現した本事例は、オープンソースAIインフラに対する攻撃が、より精密かつ目的志向型へと進化していることを示しています。
結論
CVE-2026-42208は、AIインフラのセキュリティに対して新たな警戒を求める事例です。LiteLLMは、わずか2か月の間に、サプライチェーン攻撃と直接的なSQLインジェクションという2つの経路で標的となりました。侵害経路は異なっていましたが、攻撃者の狙いは一貫していました。AIゲートウェイが管理するクラウド認証情報です。本脆弱性が示す主な示唆は2つあります。第一に、AIゲートウェイは単なる開発利便性のためのツールではなく、組織のAIインフラ全体と接続された認証情報の保管場所であり、シークレットマネージャーと同等のセキュリティ基準を適用する必要があります。第二に、36時間という悪用までの時間は、「数日以内にパッチを適用する」という従来の対応速度では十分でないことを明確に示しています。外部に公開されたLiteLLMインスタンスがどこに存在するのかを把握し、実際に脆弱なバージョンが運用されているかを即時に確認することが、パッチ適用に先立って必要となる理由がここにあります。
なお、関連して MongooseのRCE脆弱性「CVE-2024-53900＆CVE-2025-23061」：Mongoose公開によるセキュリティリスクと対策 記事も参考にできます。
Criminal IP（criminalip.io/ja/register) に登録すると、すぐに脆弱資産の検知を開始できます。さらに、下記ボタンからデモをご依頼いただくことで、エンタープライズ環境において外部に露出した資産を対象としたCriminal IP の脅威インテリジェンス（TI）分析を直接ご確認いただけます。
本レポートは、サイバー脅威インテリジェンス検索エンジン Criminal IP のデータを基に作成されています。
今すぐCriminal IP の無料アカウントを作成すれば、本レポートで引用された検索結果を直接確認したり、さらに膨大な脅威インテリジェンスを自由に検索することができます。
データソース: Criminal IP(https://www.criminalip.io/ja), SECURITYWEEK (https://www.securityweek.com/us-federal-agencys-cisco-firewall-infected-with-firestarter-backdoor/), digwatch (https://dig.watch/updates/cisa-firestarter-malware-cisco-directive), TheHackerNews (https://thehackernews.com/2026/04/firestarter-backdoor-hit-federal-cisco.html)
