LiteLLM-Lücke CVE‑2026‑42271: Unauthentifiziertes RCE in KI-API-Gateway – CISA warnt
Eine Command-Injection-Lücke in BerriAI LiteLLM lässt sich ohne Login zu Remote-Code-Execution ketten – CISA stuft CVE-2026-42271 seit dem 8. Juni 2026 als aktiv ausgenutzt ein. Betroffen sind alle Versionen ab 1.74.2; Fix ist Version 1.83.7.
Die US-Behörde CISA hat am 8. Juni 2026 die Schwachstelle CVE-2026-42271 in den Known-Exploited-Vulnerabilities-Katalog (KEV) aufgenommen und bestätigt damit eine aktive Ausnutzung in freier Wildbahn. Betroffen ist BerriAI LiteLLM, ein weit verbreitetes Open-Source-API-Gateway für große Sprachmodelle. In Kombination mit einem Starlette-Host-Header-Bypass (CVE-2026-48710) entsteht eine vollständig unauthentifizierte Remote-Code-Execution-Kette mit dem kombinierten CVSS-Score 10.0 Critical – dem höchstmöglichen Wert.
Die Schwachstelle im Detail
CVE-2026-42271 ist eine Command-Injection-Lücke in den MCP-Test-Endpunkten von LiteLLM und wird mit CVSS 8.7 bewertet. Angreifer können über diese Endpunkte beliebige Systembefehle auf dem LiteLLM-Host einschleusen und ausführen. Für sich genommen erfordert die Lücke noch eine gültige Authentifizierung – doch in Kombination mit der zweiten Schwachstelle entfällt diese Hürde vollständig.
CVE-2026-48710 (intern auch „BadHost" genannt) ist ein Host-Header-Bypass in Starlette, dem Python-Webframework, auf dem LiteLLM aufbaut. Der Bypass erlaubt es, Authentifizierungs- und Zugriffsprüfungen zu umgehen, indem ein manipulierter Host-Header gesendet wird. Der CVSS-Score dieser einzelnen Lücke liegt bei 6.5.
Die eigentliche Gefahr liegt in der Kombination beider CVEs: Ein nicht angemeldeter Angreifer kann zunächst über CVE-2026-48710 die Zugangsprüfung aushebeln und anschließend über CVE-2026-42271 beliebigen Code auf dem Server ausführen. Das Ergebnis ist eine vollständige RCE-Kette ohne Login und ohne API-Key – CVSS 10.0 Critical.
Bin ich betroffen?
Betroffen sind alle Deployments, die LiteLLM in Version 1.74.2 bis einschließlich 1.83.6 einsetzen und dabei die MCP-Integration nutzen. Besonders exponiert sind Instanzen, deren Endpunkte /mcp-rest/test/connection und /mcp-rest/test/tools/list öffentlich oder über das interne Netz erreichbar sind.
Die aktuell eingesetzte Version lässt sich per CLI abfragen:
pip show litellm | grep VersionIst die angezeigte Versionsnummer kleiner als 1.83.7, besteht akuter Handlungsbedarf.
| CVE | Komponente | CVSS | Typ | Betroffene Versionen |
|---|---|---|---|---|
| CVE-2026-42271 | LiteLLM MCP-Endpunkte | 8.7 | Command Injection | 1.74.2 – 1.83.6 |
| CVE-2026-48710 | Starlette (BadHost) | 6.5 | Host-Header-Bypass | betroffene Starlette-Versionen |
| Kombinierte Kette | LiteLLM + Starlette | 10.0 | Unauth. RCE | wie oben |
Wie lässt sich das Problem beheben?
Der primäre Fix besteht im sofortigen Update auf LiteLLM 1.83.7 oder eine neuere Version. Das Update enthält Patches für beide Angriffsvektoren:
pip install --upgrade litellmZusätzlich empfehlen die Sicherheitsforscher folgende Sofortmaßnahmen, die unabhängig vom Update greifen sollten:
- Die verwundbaren MCP-Endpunkte (
/mcp-rest/test/connectionund/mcp-rest/test/tools/list) am vorgelagerten Reverse Proxy sperren, bis das Update eingespielt ist. - Den Netzwerkzugang auf bekannte, vertrauenswürdige IP-Adressen einschränken.
- Alle API-Keys und Secrets rotieren, die das LiteLLM-Deployment gespeichert hat – auch wenn noch keine Kompromittierung erkannt wurde, da aktive Angriffe bestätigt sind.
Wer LiteLLM über Docker betreibt, findet Hinweise zur sicheren Konfiguration von Netzwerk-Isolation und Reverse-Proxy-Regeln in der Anleitung Traefik als Docker-Reverse-Proxy mit HTTPS einrichten.
Was bedeutet das für Unternehmen?
LiteLLM ist in vielen Unternehmensumgebungen das zentrale Verbindungsstück zwischen internen KI-Anwendungen und externen Modell-Providern wie OpenAI, Anthropic oder Azure OpenAI. Genau diese zentrale Rolle macht eine kompromittierte Instanz besonders gefährlich: Angreifer erhalten nicht nur Shell-Zugriff auf den Gateway-Host, sondern auch Zugang zu sämtlichen dort hinterlegten Provider-API-Credentials.
Die Folgen einer Ausnutzung reichen von massiven, unkontrollierten API-Kosten über die Sabotage laufender KI-Dienste bis hin zur vollständigen Übernahme angebundener KI-Systeme und nachgelagerter Applikationen (Lateral Movement). Da CISA eine aktive Ausnutzung in freier Wildbahn bestätigt hat, ist von einer sofort wirkenden Bedrohung auszugehen – nicht von einer theoretischen Lücke.
Für Unternehmen, die LiteLLM als Self-Hosted-KI-Gateway betreiben, gilt daher: Das Update auf 1.83.7 ist keine optionale Wartungsmaßnahme, sondern ein Notfall-Patch mit höchster Priorität. Die CISA-KEV-Aufnahme verpflichtet US-Bundesbehörden zur Behebung innerhalb einer gesetzten Frist; Best Practice für alle anderen Organisationen ist die sofortige Umsetzung.
Wer LiteLLM lokal mit Ollama oder anderen Self-Hosted-Modellen betreibt, sollte zusätzlich die Netzwerksegmentierung prüfen. Die Anleitung Ollama und Open WebUI mit Docker als lokales LLM einrichten zeigt, wie sich solche Stacks isoliert betreiben lassen. Für den allgemeinen Umgang mit Server-Härtung bietet die Anleitung Linux-Server absichern mit UFW und Fail2ban einen guten Einstieg.
Quellen: The Hacker News: LiteLLM Flaw CVE-2026-42271 Exploited in the Wild | Help Net Security: LiteLLM vulnerability under active attack (CVE-2026-42271) | SOCRadar: CISA KEV – LiteLLM CVE-2026-42271 & Check Point CVE-2026-50751
