LiteLLM CVE-2026-42208：開示36時間後に悪用が始まったCVSS 9.3 SQLインジェクション

何が起きたのか

2026年4月19日、LLMゲートウェイライブラリLiteLLM（GitHub Stars 22,000以上）の重大な脆弱性がGitHub Advisoryデータベースに登録された。

CVE-2026-42208（CVSS 9.3）は認証前のSQLインジェクションで、攻撃者はLiteLLMプロキシにリクエストを1回送るだけで、プロキシのデータベースに蓄積された上流LLMプロバイダーのAPIキー一式を読み取ることができる。

そして問題はその後に起きた。GitHubアドバイザリがグローバルインデックスに登録されてから26時間7分後の4月26日16:17 UTCに、Sysdigのセンサーが最初の悪用試行を記録した。

技術的な原因：パラメータバインディングの欠如

根本原因はシンプルな実装ミスだ。

# 脆弱なコード（概念図、バージョン < 1.83.7）
async def verify_token(token: str):
    # ❌ 文字列連結でSQLを構築 → SQLインジェクション
    query = f"SELECT * FROM LiteLLM_VerificationToken WHERE token = '{token}'"
    result = await db.execute(query)
    return result

プロキシAPIキーチェックの処理で、Authorization: Bearer <value> ヘッダーの値が直接SQL文字列に連結されていた。パラメータバインディング（プレースホルダー）を使っていなかったため、単一引用符（'）を含む値でSQL文字列から脱出し、任意のSQLを追記できてしまう。

# 正しい実装（バージョン 1.83.7-stable以降）
async def verify_token(token: str):
    # ✅ パラメータバインディング → インジェクション不可
    query = "SELECT * FROM LiteLLM_VerificationToken WHERE token = $1"
    result = await db.execute(query, token)
    return result

攻撃のエントリポイント

攻撃者はLiteLLMプロキシが公開する任意のLLM APIルートを経由して悪用できる。

# 例：細工したAuthorizationヘッダーを含むリクエスト
curl -X POST https://your-litellm-proxy/chat/completions \
  -H "Authorization: Bearer ' UNION SELECT credential_values FROM litellm_credentials--" \
  -H "Content-Type: application/json" \
  -d '{"model": "gpt-4o", "messages": [{"role": "user", "content": "hello"}]}'

プロキシのエラーハンドリングパスを通じて、信頼されていない入力がクエリに到達する構造になっていた。

窃取対象：単なるDBではなくクラウドアカウント全体

攻撃の的になったテーブルは次の2つだ。

litellm_credentials.credential_values
  └─ OpenAI 組織キー（月数万ドルの利用上限を持つ場合あり）
  └─ Anthropic コンソールキー（ワークスペース管理者権限）
  └─ AWS Bedrock IAM認証情報
  └─ Google Vertex AI / Cohere / その他プロバイダーキー

litellm_config
  └─ プロキシのランタイム設定（モデルマッピング、レート制限等）

1行のlitellm_credentialsレコードに、クラウドアカウント全体への侵入口となるキーが複数格納されているケースが多い。これは典型的なWebアプリSQLインジェクションの被害範囲をはるかに超える。

影響を受けるバージョン

脆弱: >= 1.81.16, < 1.83.7
修正: 1.83.7-stable（2026年4月19日リリース）

今すぐ行うべき対応

1. バージョン確認と即時アップグレード

# 現在のバージョン確認
pip show litellm | grep Version

# 修正版へアップグレード
pip install "litellm>=1.83.7"

# Docker利用の場合
docker pull ghcr.io/berriai/litellm:1.83.7-stable

2. アップグレードが今すぐできない場合の緩和策

# litellm_config.yaml
general_settings:
  disable_error_logs: true  # エラーハンドリングパスへの到達を遮断

これにより脆弱なクエリへのパスを塞ぐことができる。ただしこれはアップグレードの代替ではなく、あくまで一時的な緩和策だ。

3. APIキーのローテーション（感染が疑われる場合）

1.83.7未満を公開ネットワークで運用していた場合、プロキシに登録していた全APIキーを失効・再発行することを強く推奨する。

# OpenAIキーのローテーション
# https://platform.openai.com/api-keys → 旧キー削除 → 新キー発行

# Anthropicキーのローテーション
# https://console.anthropic.com/settings/keys

# AWS Bedrockの場合：IAMコンソールでアクセスキーを無効化→削除→新規発行

4. ネットワーク境界の確認

LiteLLMプロキシがパブリックインターネットに公開されているかを確認する。

# セキュリティグループ / ファイアウォールルールを確認
# 社内ネットワークのみからのアクセスに制限することが望ましい
nmap -p 4000 <your-proxy-host>  # デフォルトポートは4000

なぜ36時間後に悪用されたのか

CVEが公開されると、スキャナーがGitHub Advisory DatabaseやNVDを自動的に監視し、脆弱性の詳細を解析してエクスプロイトを生成するプロセスが走る。LiteLLMの場合、脆弱性の性質（単純なSQLインジェクション）と攻撃対象の価値（LLM APIキー）が組み合わさり、攻撃者の動機が非常に高かった。

開示から悪用までのタイムライン:
  2026-04-19: 1.83.7-stableリリース + GitHubアドバイザリ登録
  2026-04-26 16:17 UTC: 最初の悪用試行を検出（Sysdig）
  ─────────────────────────────────────────
  期間: 約26時間7分

この速度は「LLM APIキーは即座に金銭化できる」という攻撃者側の計算を示している。盗んだOpenAIキーを使ったAPI無断利用は検出が遅れることが多く、窃取からキャッシュアウトまでの時間が短い。

注意点・未確認情報

実際に悪用された被害事例の件数・詳細は非公開
Sysdigが検出した悪用試行の成功/失敗の内訳は不明
1.81.16未満の旧バージョンへの影響範囲は別途確認が必要

まとめ

CVE-2026-42208はCVSS 9.3の認証前SQLインジェクションで、LiteLLM 1.81.16〜1.83.6に影響
GitHubアドバイザリ公開から36時間以内に実際の攻撃が観測されている
攻撃対象はOpenAI・Anthropic・AWS BedrockのAPIキーで、クラウドアカウント全体の侵害につながる
今すぐ: pip install "litellm>=1.83.7" でアップグレードし、APIキーをローテーション

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感