CVE: CVE-2026-42208
GHSA: GHSA-r75f-5x8p-qvmc
CVSSスコア: 9.3（緊急）
影響を受けるソフトウェア: BerriAI LiteLLM バージョン >= 1.81.16、< 1.83.7
修正バージョン: 1.83.7-stable（2026年4月19日リリース）
CISA KEV追加日: 2026年5月8日
情報源: CISA KEV、Sysdig TRT、The Hacker News、Security Affairs
BerriAIのLiteLLM Pythonパッケージにおける重大な認証前SQLインジェクションの脆弱性が、公開から36時間以内に実環境で活発に悪用されました。LiteLLMは、GitHubで22,000以上のスターを獲得しているオープンソースのAIゲートウェイであり、OpenAI、Anthropic、クラウドホスト型モデルなど、複数のLLMプロバイダーにわたるAPI呼び出しを管理するために多くの組織で広く使用されています。悪用に成功すると、認証されていない攻撃者が、LLMプロバイダーのAPIキー、クラウド認証情報、仮想キー、および支出予算設定を保存するプロキシデータベースへの読み取りおよび書き込みアクセスを取得できます。CISAは2026年5月8日にこの脆弱性を既知の悪用された脆弱性（KEV）カタログに追加しました。
LiteLLMは、OpenAI互換のREST APIを、多数のアップストリームLLMプロバイダーに対する統合フロントエンドとして公開するプロキシサーバーです。組織はこれを使用して、LLMアクセス制御を一元化し、レート制限を適用し、支出を追跡し、複数のモデルプロバイダーにわたる認証情報を単一のポイントから管理します。プロキシは、APIキーとクラウドプロバイダーの認証情報をPostgreSQLバックエンドデータベースに保存します。
一元化された認証情報ストレージこそが、この脆弱性を特に影響の大きいものにしている理由です。侵害されたLiteLLMインスタンスは、1つのAPIキーを露出させるだけではありません。組織がすべてのLLMプロバイダーにわたって設定した可能性のあるすべてのクラウド認証情報を露出させる可能性があります。
この欠陥は、LiteLLMのプロキシAPIキー検証プロセスに存在します。リクエストが到着すると、プロキシはAuthorization: Bearerヘッダー値をデータベースと照合して呼び出し元を認証します。影響を受けるバージョンでは、ベアラートークン値がパラメータ化された入力として渡される代わりに、SQLクエリ文字列に直接連結されていました：
# 脆弱なパターン（v1.83.7より前）
cursor.execute(f"SELECT * FROM LiteLLM_VerificationToken WHERE key = '{api_key}'")
ベアラー値に含まれる一重引用符により、攻撃者は文字列リテラルをエスケープして任意のSQLステートメントを追加できます。インジェクションポイントが認証チェック自体にあるため、これをトリガーするために有効な認証情報は必要ありません。
POST /chat/completions）に細工したHTTPリクエストを送信しますAuthorization: BearerヘッダーにSQLインジェクションペイロードが含まれていますSysdigの脅威調査チームは、以下のものを標的にした実世界の悪用試行を観測しました：
LiteLLM_VerificationTokenテーブル -- 仮想APIキーとアクセス制御| 日時 | イベント |
|---|---|
| 2026年4月19日 | パッチリリース（LiteLLM v1.83.7-stable） |
| 2026年4月20日 21:14 UTC | メンテナー側リポジトリのアドバイザリ公開 |
| 2026年4月24日 16:17 UTC | GitHubグローバルアドバイザリデータベースにアドバイザリがインデックス登録（ここで防御側フィードに表示） |
| 2026年4月26日 16:24 UTC | Sysdig TRTによる最初の悪用試行を観測 -- インデックス登録から36時間7分後 |
| 2026年5月8日 | CISAがCVE-2026-42208をKEVカタログに追加 |
36時間の悪用ウィンドウは、自動スキャンを使用して新しいCVE公開を監視し、悪用コードを迅速に開発または適応させる組織化された脅威アクターと一致しています。SQLインジェクションはよく理解された脆弱性のクラスであり、影響を受けるコードパスが特定されれば、武器化は簡単です。
機密性: 高 -- 認証情報を含むデータベースの内容が読み取り可能
完全性: 高 -- データベースが書き込み可能、キーの追加、変更、削除が可能
可用性: 中 -- データベースの変更によりプロキシを妨害可能
必要な認証: なし -- 完全に認証前
必要なネットワークアクセス: あり -- 攻撃者はプロキシポートに到達できる必要があります
これが典型的なSQLiを超えて重要な理由: LiteLLMは、認証情報管理を一元化するために特別に設計されています。侵害されたLiteLLMインスタンスを実行している組織は、OpenAI、Anthropic、Azure OpenAI、AWS Bedrock、その他のプロバイダーのAPIキーを設定している可能性があります。これらの各キーは、潜在的に大きな支出限度を持つ有料LLMサービスへのアクセスを表します。LLM支出の悪用に加えて、データベース内のクラウドプロバイダー認証情報により、AWS、Azure、またはGCP環境への横移動が可能になる可能性があります。
| ステータス | バージョン |
|---|---|
| 脆弱 | >= 1.81.16 かつ < 1.83.7 |
| パッチ適用済み | >= 1.83.7-stable |
AuthorizationヘッダーにSQLメタ文字を含むLiteLLMエンドポイントへのHTTPリクエストを探します：
Authorization: Bearer ' OR 1=1--
Authorization: Bearer '; SELECT * FROM LiteLLM_VerificationToken--
Authorization: Bearer ' UNION SELECT--
プロキシログで調査すべきインジケーター：
/chat/completions、/embeddings、またはその他のAPIルートへのリクエストLiteLLM_VerificationTokenに対する予期しないSELECTクエリ| 手法 | ID | 説明 |
|---|---|---|
| 公開アプリケーションの悪用 | T1190 | インターネットからアクセス可能なLiteLLMプロキシに対するSQLインジェクション |
| パスワードストアからの認証情報取得 | T1555 | プロキシデータベースからのAPIキーとクラウド認証情報の抽出 |
| 有効なアカウント：クラウドアカウント | T1078.004 | 悪用後の盗まれたクラウドプロバイダー認証情報の使用 |
即時（影響を受けるバージョンを実行している場合）：
短期： 5. LiteLLMプロキシポートへのネットワークアクセスを制限 -- 前面に認証なしで直接インターネットに公開すべきではない 6. 将来のインジェクション試行を検出するためにデータベースクエリログを有効化 7. SQLメタ文字についてAuthorizationヘッダーを検査するWAFルールを追加
継続： 8. CISA KEVアラートを購読 -- この脆弱性は、ほとんどのパッチサイクルが追いつく前に積極的に悪用されていました 9. AIインフラストラクチャを高価値の認証情報ストアとして扱う -- シークレットマネージャーに適用されるのと同じセキュリティ制御をLLMプロキシのデプロイにも適用すべき
AIインフラストラクチャが成長する標的である理由: LiteLLMおよび類似のツールは特権的な位置にあります。高い支出限度を持つ有料クラウドサービスへの認証情報を保持し、セキュリティチームではなくエンジニアリングチームによって、セキュリティレビューの成熟度が低い状態でデプロイされることがよくあります。Sysdigチームは特に、LiteLLMオペレーターが「クラウドグレードの認証情報を一元化することを信頼している」と指摘し、認証情報の窃取とLLMサービスの悪用（盗まれたAPIキーを使用して有料モデルに対して独自のクエリを実行すること）の魅力的な標的となっています。
36時間の悪用ウィンドウはベンチマークです: これは異常ではありません。脅威アクターはCVE公開フィードとアドバイザリデータベースを積極的に監視しています。広く使用されているオープンソースソフトウェアの重大な認証前脆弱性については、公開から24〜48時間以内に悪用が始まると想定してください。パッチSLAはこの現実を考慮する必要があります -- 30日間のパッチウィンドウはCVSS 9以上の認証前脆弱性には適切ではありません。
優先順位付けシグナルとしてのCISA KEV: KEVカタログには、確認された実世界での悪用がある脆弱性のみが含まれます。CVEがKEVに表示された場合、それは理論上のものではありません -- 誰かがすでに実際の標的に対して使用しています。組織は、内部のCVSSベースの優先順位付けしきい値に関係なく、KEVへの追加を即時のアクション項目として扱うべきです。