LiteLLM の SQL インジェクション CVE-2026-42208 を理解して検知・緩和する

LLM API を OpenAI 互換の形式で中継する AI ゲートウェイ LiteLLM に、認証まわりの深刻な SQL インジェクション CVE-2026-42208（CVSS 9.8 Critical、CISA KEV 登録）が公表された。プロキシを社内外に公開して複数のLLMプロバイダを束ねている構成では影響が大きい。ここでは仕組みを最小コードで再現し、自分の環境の確認とアップグレードまでを実際に手を動かして確かめる。

何が起きるのか

影響を受けるのは LiteLLM 1.81.16 以上 1.83.7 未満。プロキシの API キー検証時に走る DB クエリが、呼び出し側が渡したキー値をパラメータ化せずにクエリ文字列へ連結していた。その結果、認証前の攻撃者が細工した Authorization ヘッダを任意の LLM API ルート（例: POST /chat/completions）へ送るだけで、エラー処理の経路を通じてこのクエリに到達できる。プロキシの DB を読み取り、場合によっては改ざんもでき、プロキシが管理する各プロバイダの認証情報漏えいにつながる。1.83.7 で修正済みだ。

SQLi の芯を最小コードで再現する

問題の本質は「ユーザー入力を文字列連結でクエリに混ぜた」こと。これを SQLite で安全に再現すると、危険性がはっきり見える。以下は攻撃を模した最小例で、実際に手元で動く。

# sqli_demo.py — 文字列連結クエリの危険性を SQLite で再現（学習用）
import sqlite3

db = sqlite3.connect(":memory:")
db.executescript("""
CREATE TABLE api_keys(token TEXT, user TEXT, secret TEXT);
INSERT INTO api_keys VALUES ('sk-alice','alice','provider-key-alice');
INSERT INTO api_keys VALUES ('sk-bob','bob','provider-key-bob');
""")

def lookup_vulnerable(token):
    # NG: 呼び出し側の値をクエリ文字列に連結している
    q = "SELECT user, secret FROM api_keys WHERE token = '" + token + "'"
    return db.execute(q).fetchall()

def lookup_safe(token):
    # OK: プレースホルダで値を分離して渡す
    q = "SELECT user, secret FROM api_keys WHERE token = ?"
    return db.execute(q, (token,)).fetchall()

# 正規のトークンは1件だけ返る
print("normal :", lookup_vulnerable("sk-alice"))

# 細工した Authorization 相当の値で全件を吸い出せてしまう
inj = "' OR '1'='1"
print("inject :", lookup_vulnerable(inj))   # 全ユーザーの secret が漏れる
print("safe   :", lookup_safe(inj))         # パラメータ化なら 0 件

実行すると、連結版 lookup_vulnerable は ' OR '1'='1 で全レコードの secret を返してしまうのに対し、プレースホルダを使う lookup_safe は 0 件を返す。

python3 sqli_demo.py
# normal : [('alice', 'provider-key-alice')]
# inject : [('alice', 'provider-key-alice'), ('bob', 'provider-key-bob')]
# safe   : []

CVE-2026-42208 も構造は同じで、認証キーの値がクエリ文字列に混ざったことが原因だ。修正は「値をパラメータとして分離する」ことに尽きる。

自分の環境を確認する

導入済みのバージョンを確認し、影響範囲（1.81.16〜1.83.7 未満）に入っていないかを見る。

# インストール済みバージョンを確認
pip show litellm | grep -i version
# もしくは
python3 -c "import litellm, sys; print(litellm.__version__)"

コンテナで動かしているなら、稼働中イメージのタグも確認する。

docker ps --format '{{.Image}}' | grep -i litellm

緩和とアップグレード

対応の基本は修正版へ更新すること。

# pip 運用
pip install -U 'litellm>=1.83.7'

# コンテナ運用は 1.83.7 以降のイメージへ差し替えて再デプロイ
# 例: ghcr.io / docker のタグを v1.83.7-stable 以降に固定する

即時更新できない場合の暫定策は、暴露面を減らすことだ。

• プロキシをインターネットに直接公開せず、内部ネットワークや認証プロキシ配下に隔離する
• WAF で異常な Authorization ヘッダ（SQL メタ文字を含むもの）を遮断する
• 更新後、DB に保管された各プロバイダの API キーはローテーションを検討する

深刻度の高い脆弱性は、クラウド別（AWS / GCP / Azure / Linux）の対応整理も含めて脆弱性対応ウォッチに日本語でまとめている。CVE-2026-42208 のパッチ状況や、同時期に KEV 登録された Drupal / Joomla の脆弱性もあわせて確認できる。

まとめ

CVE-2026-42208 は「ユーザー入力をクエリ文字列に連結した」古典的な SQLi が、AI ゲートウェイという新しい場所で再発した例だ。芯は最小コードで再現できるほど単純で、対策もパラメータ化 = 修正版への更新という一点に集約される。まず litellm のバージョンを確認し、1.83.7 未満なら早めに上げておこう。