CVE-2026-42208はGHSA-r75f-5x8p-qvmcとして追跡されており、LiteLLMにおける重大な認証前SQLインジェクションです。LiteLLMはOpenAI、Anthropic、およびその他のモデルプロバイダーのフロントエンドとして使用される22,000以上のGitHubスターを持つオープンソースLLMゲートウェイです。脆弱性公開によれば、LiteLLMはAuthorization: Bearerヘッダー値をパラメータ化されていないSQLクエリで使用しているため、LiteLLMプロキシに到達できる攻撃者は認証情報なしでPostgreSQLバックエンドに対して任意のSELECTステートメントを実行できます。
このアドバイザリは2026年4月24日16:17 UTCにGitHub Advisory Databaseにインデックスされており、執筆時点ではCISAのKEVカタログに含まれていません。タイムラインはグローバルデータベース公開に基づいており、これはディフェンダーフィード（Dependabot、OSV、GHSAミラーなど）がアドバイザリをサーフェスする時期です。メンテナー側のリポジトリアドバイザリは4月20日21:14 UTCに公開されていました。
Sysdig脅威研究チーム（TRT）はアドバイザリがグローバルデータベースに公開されてから36時間7分後に最初の悪用試行を観察しました。Sysdig TRTがキャプチャしたトラフィックは、SQLインジェクション攻撃で非常に一般的な一般的なSQLmap スプレーではなく、本番LiteLLMスキーマの意図的で、おそらくカスタマイズされた列挙であり、最も高い値のシークレットを保持する3つのテーブルをターゲットにしていました：仮想APIキー、保存されたプロバイダー認証情報、およびプロキシの環境変数設定です。オペレータはLiteLLMのPrismaで生成されたPostgreSQL識別子のケーシングをすでに知っており、各ターゲットテーブルに対して教科書的な列数検出スウィープを実行しました。
しかし、フォロースルーは見られませんでした。悪用されたキーを使用した認証済み呼び出し、/key/generate経由の仮想キー作成、またはプロバイダー認証情報の連鎖した再利用はありませんでした。この知見の新規性は、確認されたコンプロミズではなく、スキーマ列挙試行の速度と精度です。
タイムライン
|
時間（UTC） |
イベント |
|---|---|
|
2026-04-20 21:14 |
アドバイザリGHSA-r75f-5x8p-qvmcはLiteLLMリポジトリセキュリティタブで公開 |
|
2026-04-24 16:17 |
アドバイザリはグローバルGitHub Advisory Databaseにインデックス（Dependabot、OSV、およびGHSAミラーに表示） |
|
2026-04-26 04:24 |
最初のSQLインジェクション試行は65.111.27.132から観察（3xK Tech GmbH、AS200373） |
|
2026-04-26 04:24-04:45 |
スキーマ列挙フェーズ：17個のUNIONペイロード、3つのターゲットテーブル |
|
2026-04-26 05:06 |
2番目の送信IP 65.111.25.67（同じ/22、同じAS）はペイロードセットを再度再生してから、認証なしで/key/generateおよび/key/infoをプローブ |
アドバイザリ公開から最初のエクスプロイトまでの時間：36時間7分。
脆弱性
LiteLLMは、数十のアップストリームLLMプロバイダーにOpenAI互換REST APIを公開するプロキシです。オペレータは管理UIを通じてモデル定義、仮想APIキー、支出予算、およびプロバイダー認証情報を設定します。返却に、クライアントはAuthorization: Bearer sk-...を送信し、プロキシはキーを検証し、レート制限を適用し、アップストリームモデルに転送します。
CVE-2026-42208はプロキシ検証ステップ内に存在します。影響を受けるバージョン（>= 1.81.16、< 1.83.7）では、Bearer値はLiteLLM_VerificationTokenテーブルに対するSELECTに直接連結され、パラメータバインディングはありません。単一引用符により、攻撃者は文字列リテラルをエスケープし、任意のSQLを追加できます。同様の欠陥が最近ingress-nginxで報告されました。呼び出しは認証（auth）が決定される前に発生するため、インジェクションは完全に認証前です：プロキシポートに到達できるすべてのHTTPクライアントで十分です。
このアドバイザリを機会主義的なオペレータにとって特に魅力的にしたいくつかの要因があります：
- 認証前：インジェクションは認証チェック自体で実行され、レート制限、IPアローリスト、またはキャプチャがありません。ポート4000に到達できるものはすべて悪用可能です。
- プロバイダーキーへの直接パス：LiteLLMの目的は、支払いモデルプロバイダー認証情報を一元化することです。パッチノートは3つの高価値テーブルを指摘しています：
LiteLLM_VerificationToken（マスターキーを含む仮想APIキー）、litellm_credentials（保存されたプロバイダー認証情報）、およびlitellm_config（プロキシ環境変数）。3つすべてが単一のUNIONから到達可能です。 - 認証済み再利用は簡単：仮想キーまたはマスターキーが悪用されると、任意のIPから
/chat/completionsに対してリプレイできます。LiteLLMはデフォルトではキーをソースにバインドしません。
v1.83.7での修正（https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable）は、文字列補間をパラメータ化クエリに置き換えます。バージョン1.81.16～1.83.6を使用しているオペレータは直ちにパッチを適用し、露出期間中のインターネット対応インスタンスをコンプロミズされたものとして扱う必要があります。
Sysdig TRTが観察したもの
悪質なアクティビティは、2つの隣接する送信IPにわたって同じオペレータが駆動する2つのフェーズに分かれ、その後キー管理エンドポイントの簡潔な認証なしプローブが続きました。
フェーズ1：スキーマ列挙（04:24-04:45 UTC）
最初のソースIP 65.111.27.132は正規の概念実証（PoC）形状で開かれました：POST /chat/completionsはAuthorization: Bearer sk-litellm'<UNION SELECT ...>--を運搬します。sk-litellm'プレフィックスは実際のキーではありません。これは仮想キープレフィックスのように見え、SQLリテラルから抜け出すように設計された単引用符で終了した文字列です。すべてのリクエストのUser-AgentはPython/3.12 aiohttp/3.9.1です。
最初の4つのペイロードはそれぞれ異なる高価値テーブルをターゲットにしました：
sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL FROM litellm_verificationtoken--
sk-litellm' UNION SELECT credential_values,NULL,NULL,NULL,NULL FROM litellm_credentials--
sk-litellm' UNION SELECT config_value,NULL,NULL,NULL,NULL FROM litellm_config WHERE param_name='environment_variables'--
sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL FROM "LiteLLM_VerificationToken"--
2つのオペレータレベルの詳細が目立ちます：
まず、オペレータはすでに実際のテーブル名を知っていました。 PostgreSQLは引用符付きでないIDを小文字に折ります。LiteLLMのPrisma ORMはPascalCase（LiteLLM_VerificationToken）でテーブル名を生成します。小文字形式が行を返さなかった場合、オペレータは引用符付きのPascalCase形式で再試行しました。これはジェネリックスキャナーの動作ではありません。これはLiteLLM PrismaスキーマまたはLLMアシスタンスの事前読み取りを示唆しています。
次に、オペレータは最初の試行で3つの最高価値テーブルすべてを選択しました。 litellm_credentials.credential_valuesは実際のアップストリームプロバイダーキー（OpenAI、Anthropic、Bedrock）を保持しています。litellm_configとparam_name='environment_variables'はプロキシランタイムenvを返し、通常はPostgreSQL DSN、マスターキー、コールバックウェブフックURL、およびキャッシュバックエンドを含みます。litellm_usersまたはlitellm_teamのような無実のテーブルに対するプローブはありませんでした。オペレータはシークレットが存在する場所に直行しました。
10分間の一時停止後、同じIPが列数列挙のために戻ってきました。NULLプレースホルダーの数を変動させて、基本的なクエリ形状を発見しました：
sk-litellm' UNION SELECT api_key FROM litellm_verificationtoken--
sk-litellm' UNION SELECT api_key,NULL FROM litellm_verificationtoken--
sk-litellm' UNION SELECT api_key,NULL,NULL FROM litellm_verificationtoken--
sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL FROM litellm_verificationtoken--
sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL,NULL FROM litellm_verificationtoken--この進行（1、2、3、5、6列）は、アプリケーションがUNION出力の1列のみを破棄する場合に列数を見つけるための教科書的な方法です。正しい形状が到達すると、その列は応答本文でリークされたデータを返します。
フェーズ2：送信ローテーション、同じオペレータ（05:06 UTC）
21分間の一時停止後、2番目のソースIP 65.111.25.67（同じ/22サブネット、同じAS200373、同じUser-Agent）は25秒のスパンでペイロードセットを再度実行しました。同一のテンプレートとペーシングは、目標間の送信をローテーションする単一オペレータ読み取りをより簡潔にします。ギャップとIP変更は、IPごとのレート制限をバイパスするために送信IPをロールするツールと一致しています。
2番目のIPのペイロードは洗練されたターゲットリストに収束しました：
sk-litellm' UNION SELECT api_key FROM "LiteLLM_VerificationToken"--
sk-litellm' UNION SELECT api_key,NULL FROM "LiteLLM_VerificationToken"--
sk-litellm' UNION SELECT api_key,NULL,NULL FROM "LiteLLM_VerificationToken"--
sk-litellm' UNION SELECT credential_values,NULL,NULL FROM litellm_credentials--
sk-litellm' UNION SELECT config_value,NULL FROM litellm_config WHERE param_name='environment_variables'--
sk-litellm' OR 1=1--
最後のOR 1=1--ペイロードが最も示唆的です。29のUNIONバリアント後、最後のリクエストはトートロジーに低下しました：「他のすべてが失敗した場合、任意の行を返します。」これは自動化ハーネスのペイロードリストを枯渇させる形状であり、人間の入力者ではありません。
ディフェンダーにとって意味すること
LiteLLMへのアドバイザリから最初のエクスプロイトまでの36時間のウィンドウは、最近のmariomoの脆弱性の悪用よりも遅い曲線ですが、ターゲティングはより意図的でした。mariomoのエクスプロイトはジェネリック対話型シェルスマッシュアンドグラブでした。LiteLLMの試みはプロキシの最も価値のあるシークレットを保有する3つの特定のテーブルに対する抽出に焦点を当てました。
強調する価値のあるいくつかのパターン：
- AIプロキシはクラウドグレード認証情報を集約します。 単一の
litellm_credentials行はしばしば5桁の月額支出キャップを持つOpenAI組織キー、ワークスペース管理者権限を持つAnthropicコンソールキー、およびAWS Bedrock IAM認証情報を保持しています。成功したデータベース抽出のブラスト半径は、典型的なWebアプリSQLインジェクションよりもクラウドアカウントコンプロミズに近いです。このオペレータはlitellm_credentials.credential_valuesとlitellm_config.config_value WHERE param_name='environment_variables'を直接ターゲットにしました。彼らは何が危機に瀕しているかを理解しました。 - スキーマナレッジは悪用に先行します。
litellm_verificationtokenから"LiteLLM_VerificationToken"への再試行はジェネリックスキャナーの動作ではありません。これはオペレータがLiteLLM Prismaスキーマを実行前に読んだことを示唆しています。 - GHSA限定の重大アドバイザリはKEVレベルの緊急性が必要です。 CVEキー付きアラート化またはCISA KEV取り込みに依存するディフェンダーは、この記事公開メッセージを時間内にサーフェスしません。
コンプロミズの指標
ソースIP
|
IP |
ASN / オペレータ |
国 |
アクティビティ |
|---|---|---|---|
|
65.111.27.132 |
AS200373、3xK Tech GmbH |
DE |
UNIONベースのSQLインジェクション、スキーマ列挙、列数発見（04:24-04:45 UTC） |
|
65.111.25.67 |
AS200373、3xK Tech GmbH |
DE |
UNIONベースのSQLインジェクション、洗練されたペイロードセット、ターミナルOR 1=1、認証なしの/key/generateおよび/key/infoプローブ（05:06 UTC） |
両方のIPは同じ自律システムの隣接する/22ブロックに位置し、同じPython/3.12 aiohttp/3.9.1 User-Agentを使用しており、2つのリクエスト間で送信をローテーションする単一オペレータではなく別のアクターと一致しています。ソースIPはオペレータの真の起源ではなく、プロキシまたはレンタルVPSエンドポイントである可能性があります。
リクエストシグネチャ
- HTTPリクエスト：
POST /chat/completions、オプションで/v1/chat/completionsが続きます。空または75バイトのボディ。 - すべてのSQLインジェクションリクエストのUser-Agent：
Python/3.12 aiohttp/3.9.1。 - Authorization: Bearerヘッダーは
sk-litellm'（単一引用符ターミネータ）で始まります。 UNION SELECT、FROM litellm_verificationtoken、FROM "LiteLLM_VerificationToken"、FROM litellm_credentials、またはFROM litellm_config WHERE param_name='environment_variables'を含むヘッダー値。
推奨事項
- 更新 LiteLLMをv1.83.7（https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable）以降に直ちに。パッチウィンドウが利用できない場合は、単一引用符、括弧、またはSQLキーワード（UNION、SELECT、FROM、OR、–）を含む任意のAuthorizationヘッダー値をブロックするリバースプロキシの後ろにプロキシを配置します。
- ローテーション インターネット到達可能な脆弱なバージョンにあった任意のLiteLLMインスタンスに保存されているすべての仮想APIキー、マスターキー、およびプロバイダー認証情報。確認された抽出がない場合でも、データベースがコンプロミズされたものとして扱われます。
- 監査 パッチの後の数日間の予期しないIPからのアップストリームプロバイダー請求で
/chat/completionsトラフィック。予期しないソースIPからのマスターキー再利用は、最も信頼できるマネタイゼーション信号です。 - 制限 LiteLLMプロキシを内部ネットワークまたは相互認証済みリバースプロキシに。AIゲートウェイは十分な認証情報値を統合するため、直接のインターネット露出はもはや防御可能なデフォルトではありません。
- 監視 Webサーバーログで上記のリクエスト形状。パッチ前にBearerが
sk-litellm'であるリクエストは、試行されたエクスプロイトの高信頼度インジケーターです。 - インベントリ 環境内のAIプロキシとゲートウェイデプロイメント。アプリケーションチームは頻繁にLiteLLM、OpenLLM、OpenAI互換拠点、および同様のツールを標準的なセキュリティレビュー外で立ち上げ、監視なしで本番レベルのプロバイダーキーを保有する可能性があります。
結論
LiteLLM脆弱性（GHSA-r75f-5x8p-qvmc）は、AIインフラストラクチャアドバイザリのモーダルパターンを継続します：重大、認証前、および5桁のスター数を持つソフトウェアであり、オペレータはクラウドグレード認証情報を一元化するために信頼します。36時間のエクスプロイトウィンドウはZero Day Clockで文書化された広い崩壊と一致しており、我々が記録したオペレータの動作（逐語的なPrismaテーブル名、3テーブルターゲティング、意図的な列数列挙）は、悪用がもはや公開PoC を待たないことを示しています。アドバイザリとオープンソーススキーマは最終的に十分でした。
Sysdig TRTは成功した認証済みフォローオンを観察しませんでした。これはその脆弱性が無実であることを意味しません、しかしこのオペレータが使用可能なキーの抽出に失敗したか、彼らが抽出したものをマネタイズしないことを選択したことを意味します。どちらにせよ、スキーマ列挙フェーズのターゲティング精度は、AIゲートウェイデータベースがディフェンダーにとって明示的な目標になったことを示しています。
AIゲートウェイカテゴリー（プロキシ、キーマネージャー、モデルルーター等）は、開発者の利便性としてではなく、tier-1認証情報サーフェスとして扱われる必要があります。LiteLLMデータベースに対するSQLインジェクションは、実際には、それが面するすべてのモデルプロバイダーアカウントに対するSQLインジェクションです。
クラウド検出とレスポンス
