.png)
Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年4月27日に Michael Clark が投稿したブログ(https://www.sysdig.com/blog/cve-2026-42208-targeted-sql-injection-against-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure)を元に日本語に翻訳・再構成した内容となっております。
CVE-2026-42208（GHSA-r75f-5x8p-qvmcとして追跡）は、LiteLLMにおける重大な事前認証SQLインジェクションであり、LiteLLMは22,000以上のGitHubスターを持つオープンソースのLLMゲートウェイで、OpenAI、Anthropic、その他のモデルプロバイダーのフロントエンドとして使用されています。脆弱性の公開によると、LiteLLMはパラメータ化されていないSQLクエリでAuthorization: Bearerヘッダーの値を使用しているため、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を用いた仮想キーの生成、プロバイダー資格情報の連鎖的な再利用も見られませんでした。この発見の新規性は、スキーマ列挙の試行の速度と精度にあり、侵害が確認されたわけではありません。
タイムライン
アドバイザリ公開から最初の悪用までの時間：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）の形式で開始しました。すなわち、Authorization: Bearer sk-litellm’<UNION SELECT …>– を含む POST /chat/completions です。sk-litellm’ というプレフィックスは実際のキーではありません。これは仮想キーのプレフィックスに見えるように設計され、SQLリテラルから抜け出すための、シングルクォートで終端された文字列です。すべてのリクエストのユーザーエージェントは 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では引用符のない識別子は小文字に変換されますが、LiteLLMのPrisma ORMはPascalCase（LiteLLM_VerificationToken）でテーブル名を生成します。小文字形式で結果が返らなかったため、オペレーターは引用符付きのPascalCase形式で再試行しました。これは一般的なスキャナーの挙動ではありません。LiteLLMのPrismaスキーマを事前に読んでいたか、LLMの支援を受けていたことを示唆しています。
第二に、オペレーターは最初の試行で最も価値の高い3つのテーブルすべてを選択しました。litellm_credentials.credential_valuesには実際の上流プロバイダーキー（OpenAI、Anthropic、Bedrock）が格納されています。param_name=‘environment_variables’のlitellm_configは、通常PostgreSQLのDSN、マスターキー、コールバックWebhook 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、同一のユーザーエージェント）が、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時間という期間は、最近のmarimo脆弱性の悪用よりも遅いペースですが、標的設定はより意図的でした。marimoの悪用は汎用的なインタラクティブシェルによる一括取得型でしたが、LiteLLMの試行はプロキシの最も価値の高いシークレットを保持する3つの特定テーブルに対する抽出に焦点を当てていました。
いくつかの重要なパターンがあります：
- AIプロキシはクラウドレベルの認証情報を集約します。単一のlitellm_credentials行には、月間数万ドル規模の支出上限を持つ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は同一の自律システム内の隣接する/22ブロックに位置し、同じPython/3.12 aiohttp/3.9.1のユーザーエージェントを使用しており、別々の攻撃者ではなく、単一のオペレーターが2つのリクエスト間で送信元を切り替えていることと一致しています。送信元IPは、オペレーターの実際の発信元ではなく、プロキシやレンタルされたVPSエンドポイントである可能性があります。
リクエストシグネチャ
- HTTPリクエスト：POST /chat/completions、場合によっては続けて /v1/chat/completions。本文は空、または75バイト。
すべてのSQLインジェクションリクエストのユーザーエージェント：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’ リクエストは、たとえ1件であっても、悪用試行を示す信頼度の高い指標です。
- 環境内のAIプロキシおよびゲートウェイのデプロイを棚卸ししてください。アプリケーションチームは、LiteLLM、OpenLLM、OpenAI互換の踏み台、および同様のツールを標準的なセキュリティレビューの外で構築することが多く、監視なしで本番レベルのプロバイダーキーを保持している可能性があります。
まとめ
LiteLLMの脆弱性（GHSA-r75f-5x8p-qvmc）は、AIインフラに関するアドバイザリにおける典型的なパターンを踏襲しています。すなわち、重大で、事前認証であり、かつクラウドレベルの資格情報を一元管理するために運用者が信頼している、数万規模のスターを持つソフトウェアに存在しています。36時間という悪用までの時間は、Zero Day Clockによって記録されている広範な短縮傾向と一致しており、私たちが観測したオペレーターの挙動（Prismaのテーブル名のそのままの使用、3テーブルの標的化、意図的なカラム数列挙）は、もはや公開されたPoCを待たずに悪用が行われていることを示しています。最終的には、アドバイザリとオープンソースのスキーマだけで十分でした。
Sysdig TRTは、認証後の成功した追跡的な活動は観測していません。これはこの脆弱性が無害であることを意味するものではありませんが、このオペレーターが有用なキーの抽出に失敗したか、あるいは抽出したものを収益化しなかったことを意味します。いずれにしても、スキーマ列挙フェーズにおける標的設定の精度は、AIゲートウェイのデータベースが現在明確な攻撃対象となっていることを防御側に示しています。
AIゲートウェイというカテゴリ（プロキシ、キーマネージャー、モデルルーターなど）は、開発者の利便性のためのものではなく、最重要レベルの資格情報の攻撃面として扱う必要があります。LiteLLMデータベースに対するSQLインジェクションは、実質的には、それがフロントしているすべてのモデルプロバイダーアカウントに対するSQLインジェクションに等しいものです。