Fast jedes zehnte LiteLLM-Gateway, das über das Internet erreichbar ist, akzeptiert den Standard-Administrator-Schlüssel sk-1234. Diesen Wert listet die offizielle Setup-Anleitung des Open-Source-KI-Gateways als Beispiel. Unternehmen setzen LiteLLM als Vermittler zwischen ihren Anwendungen und den von ihnen bezahlten KI-Modellaaaa-Anbietern ein. Wer über diesen Schlüssel verfügt, kann sämtliche API-Keys der Modellanbieter auf dem Server auslesen. In Tests der Sicherheitsfirma Wiz Research gelang damit sogar der Zugriff auf die Cloud-IAM-Anmeldeinformationen der zugrunde liegenden Maschine. Ein Austausch des Schlüssels erfordert kein Upgrade und schließt sämtliche Angriffspfade, die von seiner Kenntnis abhängen.
Die Zahlenbasis der Untersuchung
Wiz führte im Februar einen einzelnen Scan durch und identifizierte 3.074 LiteLLM-Gateways auf der Suchmaschine Shodan. Von diesen akzeptierten 294 den Standardschlüssel. Bei 191 dieser 294 Systeme war überhaupt kein Schlüssel gesetzt, sodass sie jede Anfrage akzeptiert hätten. Bei den restlichen Systemen war der Beispielwert aus der Anleitung unverändert hinterlegt. Ein zweiter Scan im August entdeckte über 85.000 Instanzen, doch Wiz zufolge handelt es sich bei den meisten um Honeypots oder Testsysteme, weshalb die Zahlen nicht vergleichbar sind. Eine aktuelle Zahl existiert nicht. Die Setup-Anleitung von LiteLLM verwendet noch immer sk-1234codecodecodecodecode – oberhalb eines Kommentars, der Betreiber auffordert, diesen vor dem produktiven Einsatz durch einen langen, zufälligen Wert zu ersetzen.
Warum ein einziger Schlüssel derart schwerwiegend ist
Der Masterschlüssel übernimmt gleich zwei Aufgaben, was einen voreingestellten Wert so kritisch macht: Er dient als Admin-Anmeldedaten und schaltet die Authentifizierung frei. In Versionen vor 1.82.0-stable gewährte ein Gateway ohne gesetzten Masterschlüssel jeder eingehenden Anfrage vollständige Admin-Rechte. Ein Administrator auf einem solchen Server hat weitreichende Möglichkeiten: Das Gateway kann API-Keys für alle angebundenen Anbieter speichern, sämtliche Prompts und Antworten einsehen und über das Model Context Protocol (MCP) Verbindung zu internen Tools aufnehmen. Da es zudem meist mit den Cloud-Berechtigungen der eingesetzten Workload läuft, ermöglichten gestohlene Provider-Keys einem Angreifer, Modell-Workloads auf Kosten des Opfers auszuführen – ein Missbrauch, der als LLMjacking bekannt ist.
Der Weg zum Cloud-Konto
LiteLLM erlaubt Administratoren die Einrichtung eines Durchgangs-Endpunkts, einer Route, die Anfragen an jede vom Admin gewählte URL weiterleitet. Die Ziel-URL wird nicht auf private Adressbereiche, Localhost oder Cloud-Metadaten-Adressen geprüft. Ein Admin kann daher eine Route auf den Metadaten-Dienst der Instanz leiten und die zurückgegebenen IAM-Anmeldeinformationen auslesen. Der Wechsel zu IMDSv2 verhindert dies nicht: LiteLLM dokumentiert, dass jeder Header mit dem Präfix x-pass-codecodecodecodecode an das Ziel weitergeleitet wird (wobei das Präfix entfernt wird), und Wiz nutzte dies, um die für IMDSv2 erforderlichen Header zu senden. Es gibt keine Berichte, dass dies gegen eine reale Installation eingesetzt wurde; es handelt sich um eine Demonstration, die zunächst Admin-Zugriff erfordert. Wiz stellt fest, dass diese Funktion im Grunde wie vorgesehen funktioniert, da das Bedrohungsmodell von LiteLLM Administratoren als vertrauenswürdig einstuft. Es gibt weder eine CVE noch einen Fix. Das Projekt selbst vertritt eine ähnliche Position: Seine veröffentlichte Sicherheitsrichtlinie listet Angriffe, die auf einen Einrichtungsfehler (wie das Fehlen eines Masterschlüssels) angewiesen sind, als „explizit nicht im Rahmen“ und damit nicht als Schwachstellen.
Die Guardrail-Schwachstelle und ein umstrittener Schweregrad
Die einzige Schwachstelle zur Codeausführung in Wiz‘ Bericht ist CVE-2026-59821. Forscher und Maintainer beschreiben sie jedoch sehr unterschiedlich. Wiz spricht von Codeausführung nach Authentifizierung auf Root-Ebene und zeigt einen Test, der uid=0(root)codecodecodecodecode im Gateway-Container zurückgibt. LiteLLMs Advisory für dieselbe CVE bewertet sie als Niedrig (2.1 auf der CVSS-Skala) und beschreibt eine Schwachstelle, die ein Konto mit hohen Privilegien voraussetzt. Beide Beschreibungen beziehen sich auf dasselbe Verhalten: Vor Version 1.82.0-stable umgingen die Endpunkte zum Erstellen und Aktualisieren von benutzerdefinierten Code-Guardrails die Sandbox- und Musterprüfungen des Test-Endpunkts, sodass jeder mit Zugriff Python-Code innerhalb des Containers ausführen konnte. Das Advisory fügt hinzu, dass eine Installation ohne Masterschlüssel Aufrufer als Proxy-Administratoren behandelte, was diese Endpunkte erreichbar machte. Nach Version 1.82.0 konnte ein Angreifer mit dem Standardschlüssel laut Wiz nur noch innerhalb einer Sandbox Code ausführen. Ein separates Advisory von Mai, CVE-2026-40217, stellt fest, dass die Sandbox mit Bytecode-Techniken umgangen werden konnte, indem Code im Proxy-Prozess ausgeführt wurde (der im Standard-Docker-Image als root läuft). Es betrifft Versionen von 1.81.8 bis einschließlich 1.83.9; der Zugriff auf den Endpunkt erfordert einen Proxy-Admin-Nachweis – der Masterschlüssel ist dieser Nachweis. Beide von Wiz gemeldeten Schwachstellen wurden Monate vor dem Bericht im September (Februar und April) behoben; ihre CVEs wurden im Juli veröffentlicht.
Separate Bedrohung: Bereits ausgenutzte LiteLLM-Schwachstellen
Hierbei handelt es sich um ältere Probleme, die nichts mit dem oben beschriebenen Weg zu Cloud-Anmeldedaten zu tun haben. Sie werden aufgeführt, da sie dasselbe Produkt betreffen und leicht zu verwechseln sind. CISA nahm am 2. September eine LiteLLM-Schwachstelle in den Katalog bekannter ausgenutzter Schwachstellen auf. CVE-2026-59822 (CVSS: 8,8), ebenfalls von Wiz entdeckt, ermöglicht einem nicht authentifizierten Angreifer die Eröffnung einer gültigen MCP-Sitzung mit einem beliebigen Bearer-Token, selbst einem einzelnen Zeichen. Bundesbehörden haben bis zum 16. September Zeit, dies zu beheben. Wiz beobachtete die Ausnutzung ab dem 7. Juli in seinen Honeypots. Diese Schwachstelle erreicht nicht die Pfade zur Codeausführung oder zum Diebstahl von Anmeldedaten. Eine andere Schwachstelle, CVE-2026-42271 (CVSS: 8,7), erlaubte jedem authentifizierten Benutzer die Ausführung von Befehlen auf dem Host über zwei MCP-Test-Endpunkte. Horizon3.ai berichtete im Juni, dass dies mit einer Starlette-Host-Header-Schwachstelle, CVE-2026-48710, kombiniert werden konnte, um dasselbe ohne Anmeldedaten zu erreichen. Wiz‘ Honeypots zeichneten auf, dass diese Schwachstelle zur Installation eines Kryptominerers genutzt wurde. Microsoft veröffentlichte im August einen Fall, bei dem Angreifer Befehle in einem LiteLLM-Gateway-Prozess ausführten, die Umgebungsvariablen des Containers nach dem Masterschlüssel, Provider-Keys und der Datenbank-Verbindungszeichenfolge durchsuchten und damit auf die PostgreSQL-Datenbank zugriffen. Microsoft bewertet mit hoher Sicherheit, dass die Angreifer über das exponierte Gateway eindrangen, und fordert: „Behandeln Sie KI-Gateways als Geheimnisse der Stufe 0.“
Empfohlenes Vorgehen
Ein Upgrade auf Version 1.84.0 oder höher behebt alle genannten Schwachstellen. Folgende Schritte sind essenziell:
- Masterschlüssel ändern: Ersetzen Sie
sk-1234codecodecodecodecode durch einen langen, zufälligen Wert. Dies erfordert kein Upgrade. Prüfen Sie vorab, ob ein separater Salt-Key gesetzt ist, da das Rotationsverfahren abweicht. - Auf Version 1.84.0 oder höher aktualisieren: Diese Version liegt über der fixierten Version jeder Schwachstelle in der Tabelle.
- Bei aufgeschobenem Upgrade: Blockieren Sie die Pfade
/mcp/codecodecodecodecode,POST /mcp-rest/test/connectioncodecodecodecodecode undPOST /mcp-rest/test/tools/listcodecodecodecodecode in Ihrem Reverse Proxy. - Zusätzlich blockieren:
POST /guardrails/test_custom_codecodecodecodecodecode und schränken SiePOST /guardrailscodecodecodecodecode undPUT /guardrails/{guardrail_id}codecodecodecodecode auf Administratoren ein. - Durchgangs-Endpunkte prüfen: Beschränken Sie die ausgehende Netzwerkverbindung des Containers und weisen Sie der Workload die minimal notwendige Cloud-IAM-Rolle zu.
- Bei Verdacht auf Kompromittierung: Überprüfen Sie die Guardrails-Liste, starten Sie den Prozess neu, und rotieren Sie Provider-Keys, Masterschlüssel sowie Datenbank-Anmeldedaten. Ein Upgrade entfernt weder registrierte Guardrails noch hinzugefügte SSH-Schlüssel.
Für den Durchgangsweg zu den Instanz-Metadaten gibt es keinen Patch, da LiteLLM dies nicht als Schwachstelle wertet. Netzbeschränkungen und enge IAM-Rollen sind die einzigen verfügbaren Kontrollen. Es existiert keine Anleitung zur Prüfung, ob MCP- oder Durchgangs-Routen auf einem übernommenen Gateway aktiviert sind. Die Jagdqueries von Microsoft finden Ausnutzung, nicht Konfiguration.
