Gestohlene Anbieter-Schlüssel allein reichen aus, um Modell-Workloads auf Kosten des Opfers laufen zu lassen — ein Missbrauch, der als LLMjacking bekannt ist. Darüber hinaus erlaubt LiteLLM Administratoren, einen Pass-Through-Endpunkt anzulegen, also eine Route, die Anfragen an eine beliebige vom Administrator gewählte URL weiterleitet.
Die Ziel-URL wird nicht gegen private Adressbereiche, localhost oder Cloud-Metadaten-Adressen geprüft. Ein Administrator kann eine Route damit auf den Instanz-Metadatendienst richten und die zurückgelieferten IAM-Zugangsdaten auslesen. Auch IMDSv2 verhindert das nicht: LiteLLM dokumentiert, dass jeder Header mit dem Präfix x-pass- ohne dieses Präfix an das Ziel weitergereicht wird — Wiz nutzte das, um die von IMDSv2 verlangten Header zu senden.
Dass jemand dies gegen eine echte Installation eingesetzt hätte, berichtet keine Quelle; es handelt sich um eine Demonstration, die zuvor Administratorzugang erfordert. Wiz hält das Verhalten für vertretbar bestimmungsgemäß, da LiteLLMs Bedrohungsmodell Administratoren als vertrauenswürdig einstuft. Es gibt weder eine CVE noch einen Fix. Auch die Sicherheitsrichtlinie des Projekts führt Angriffe, die einen Konfigurationsfehler wie einen fehlenden Master-Key voraussetzen, als „ausdrücklich nicht im Geltungsbereich" und nicht als Schwachstellen.
Die eine Lücke zur Codeausführung in Wiz’ Bericht ist CVE-2026-59821 — und Forscher wie Maintainer beschreiben sie sehr unterschiedlich. Wiz spricht von Codeausführung mit Root-Rechten nach Authentifizierung und zeigt einen Test, der im Gateway-Container uid=0(root) zurückgibt. Das LiteLLM-Advisory zur selben CVE stuft sie als niedrig ein (CVSS 2.1) und verweist auf das nötige hoch privilegierte Konto. Technisch ist es dasselbe: Vor 1.82.0-stable übersprangen die Endpunkte zum Anlegen und Ändern eigener Code-Guardrails die Sandbox- und Musterprüfungen des Test-Endpunkts, sodass eingereichter Python-Code im Container lief.
Wiz schreibt, nach 1.82.0 könne ein Angreifer mit dem Standardschlüssel Code nur noch in einer Sandbox ausführen. Das deckt sich nicht mit allen Releases: Ein separates Advisory vom Mai, CVE-2026-40217, beschreibt einen Sandbox-Ausbruch per Bytecode-Techniken im Proxy-Prozess, der im Standard-Docker-Image als root läuft. Betroffen sind Versionen ab 1.81.8 bis ausschließlich 1.83.10; der Zugriff verlangt Proxy-Admin-Zugangsdaten — also den Master-Key. Beide von Wiz gemeldeten Fehler wurden im Februar und April behoben, die CVEs im Juli veröffentlicht.
CISA nahm am 2. September eine LiteLLM-Lücke in den Katalog bekannter ausgenutzter Schwachstellen auf: CVE-2026-59822 (CVSS 8.8), ebenfalls von Wiz gefunden, erlaubt unauthentifizierten Angreifern, mit einem beliebigen Bearer-Token — auch einem einzigen Zeichen — eine gültige MCP-Sitzung zu öffnen. Bundesbehörden haben bis zum 16. September Zeit. Wiz beobachtete den Einsatz gegen eigene Honeypots ab dem 7. Juli, mit Ein-Zeichen-Tokens gegen Endpunkte zur Modellauflistung. Laut Wiz erlaubt die Lücke „nur Zugriff auf MCP-Server".
Zur Codeausführung genutzt wird eine andere: CVE-2026-42271 (CVSS 8.7) ließ jeden authentifizierten Nutzer über zwei MCP-Test-Endpunkte Befehle auf dem Host ausführen; Horizon3.ai berichtete im Juni, dass sich das mit der Starlette-Host-Header-Lücke CVE-2026-48710 auch ganz ohne Zugangsdaten verketten lässt. Wiz’ Honeypots zeichneten die Installation eines Kryptominers auf.
Microsoft veröffentlichte im August einen Fall, in dem Angreifer Befehle im LiteLLM-Gateway-Prozess ausführten, aus der Container-Umgebung Master-Key, Anbieterschlüssel und Datenbank-Verbindungszeichenfolge auslasen und damit auf die PostgreSQL-Datenbank zugriffen und Einträge aus den Modell- und Virtual-Key-Tabellen kopierten. Der Einstieg passe mit hoher Zuversicht zur Kette aus CVE-2026-42271 und CVE-2026-48710. „Behandeln Sie KI-Gateways wie Tier-0-Geheimnisspeicher", so das Unternehmen.
Ein Upgrade auf 1.84.0 oder neuer deckt alle genannten Fehler ab. Für den Pass-Through-Weg zu den Instanz-Metadaten gibt es keinen Patch; als Gegenmaßnahmen bleiben nur Begrenzungen des ausgehenden Netzverkehrs und eng gefasste IAM-Rollen.