LiteLLM — ein populäres Open-Source-Gateway zwischen Anwendungen und Anbietern von Sprachmodellen — ist in den Mittelpunkt einer Reihe von Sicherheitsvorfällen geraten. Laut Wiz Research akzeptierte im Februar 2026 fast jeder zehnte der im Internet entdeckten LiteLLM-Server sk-1234 — ein Beispiel für einen administrativen Schlüssel aus der offiziellen Installationsanleitung. Dieser Schlüssel eröffnet Zugriff auf alle auf dem Server gespeicherten API-Schlüssel der Modellprovider und unter bestimmten Bedingungen auch auf Cloud-IAM-Anmeldedaten. CISA hat bereits eine der LiteLLM-Schwachstellen in den Katalog der bekannt ausgenutzten Schwachstellen aufgenommen, und Microsoft sowie Wiz haben reale Angriffe mit Installation von Kryptominern und Diebstahl von Secrets registriert. Organisationen, die LiteLLM einsetzen, müssen den Master-Schlüssel umgehend ändern und auf Version 1.84.0 oder höher aktualisieren.
Ausmaß des Problems mit dem Default-Schlüssel
Nach Angaben von Wiz wurden im Februar 2026 über Shodan 3.074 öffentlich zugängliche LiteLLM-Gateways gefunden. Davon akzeptierten 294 den Schlüssel sk-1234. Bei 191 Servern war überhaupt kein Master-Schlüssel gesetzt — sie gewährten jedem Request volle Administratorrechte. Die übrigen verwendeten den in der Installationsanleitung genannten Wert unverändert. Ein erneuter Scan im August identifizierte über 85.000 Instanzen; Wiz weist jedoch darauf hin, dass es sich bei der Mehrzahl davon vermutlich um Fallen (Honeypots) oder Testsysteme handelt, sodass sich diese Zahlen nicht direkt vergleichen lassen.
Der Master-Schlüssel in LiteLLM erfüllt eine Doppelfunktion: Er dient gleichzeitig als Administrator-Anmeldedaten und als Schalter, der die Authentifizierung aktiviert. Bis Version 1.82.0-stable gewährte ein ohne Master-Schlüssel gestartetes Gateway jedem eingehenden Request volle Administratorrechte. Ein Administrator des Gateways erhält Zugriff auf alle Provider-API-Schlüssel, sieht alle durchlaufenden Requests und Antworten und kann sich außerdem über das Model Context Protocol (MCP) mit internen Tools verbinden. Gestohlene Provider-Schlüssel ermöglichen einem Angreifer, Modell-Workloads auf Kosten des Opfers auszuführen — ein Angriff, der als LLMjacking bekannt ist.
Karte der Schwachstellen: fünf CVE und ihre Zusammenhänge
Rund um LiteLLM hat sich ein ganzer Cluster von Schwachstellen gebildet. Bereits zuvor haben wir darüber geschrieben, dass eine Reihe von LiteLLM-Schwachstellen in den CISA-KEV-Katalog aufgenommen wurde. Schauen wir uns das Gesamtbild an.
CVE-2026-59822 (CVSS 8.8, High) — Umgehung der MCP-Authentifizierung. Ermöglicht es einem nicht authentifizierten Angreifer, mit einem beliebigen Bearer-Token, auch von nur einem Zeichen Länge, eine gültige MCP-Session zu eröffnen. Betrifft Versionen vor 1.84.0. Laut LiteLLM-Sicherheitshinweis in 1.84.0 behoben. CISA hat diese Schwachstelle am 2. September in den KEV-Katalog aufgenommen, mit einer Frist für Bundesbehörden bis zum 16. September. Nach Angaben von Wiz wurde die Ausnutzung in ihren Honeypots seit dem 7. Juli beobachtet — Requests mit einbuchstabigen Tokens sondierten Endpunkte zur Auflistung von Modellen. Wiz präzisiert, dass diese Schwachstelle „nur Zugriff auf den MCP-Server ermöglicht“ und der tatsächliche Schaden von den angebundenen Tools abhängt.
CVE-2026-42271 (CVSS 8.7, High) — Befehlsausführung über Test-MCP-Endpunkte. Laut GitHub-Sicherheitshinweis betrifft dies Versionen ≥1.74.2 und <1.83.7. Ein authentifizierter Benutzer mit gültigem Proxy-API-Schlüssel kann Befehle über MCP-stdio-Testendpunkte ausführen. Behoben in 1.83.7. Diese Schwachstelle war der Hauptangriffsvektor in realen Attacken.
CVE-2026-48710 (CVSS 6.5) — Umgehung der Host-Header-Prüfung in Starlette (≤1.0.0). Laut Sicherheitshinweis führen manipulierte Host-Header dazu, dass sich request.url.path vom gerouteten Pfad unterscheidet, wodurch sicherheitsrelevante Pfadprüfungen umgangen werden. Behoben in Starlette 1.0.1. Horizon3.ai hat demonstriert, dass diese Schwachstelle in Kombination mit CVE-2026-42271 eine Befehlsausführung ohne Authentifizierung ermöglicht.
CVE-2026-59821 (CVSS 2.1, Low laut Bewertung von LiteLLM CNA) — Umgehung von Sicherheitsprüfungen des Codes in den Endpunkten zum Erstellen und Aktualisieren benutzerdefinierter Guardrails. Betrifft Versionen bis 1.82.0-stable. Laut Sicherheitshinweis ist hierfür ein privilegiertes Konto erforderlich, wobei Deployments ohne konfigurierten Master-Schlüssel alle Aufrufer als Administratoren behandelten. Wiz beschreibt dasselbe Verhalten als Codeausführung mit Root-Rechten innerhalb des Gateway-Containers — eine abweichende Einschätzung der Schwere zwischen den Forschern und den Maintainern.
CVE-2026-40217 (CVSS 5.9, Moderate) — Ausbruch aus der Sandbox in benutzerdefinierten Guardrails mittels Bytecode-Techniken. Laut Sicherheitshinweis betrifft dies Versionen ≥1.81.8 und <1.83.10, obwohl in der Beschreibung des Hinweises Version 1.83.11 als Fix angegeben ist — ein interner Widerspruch. Der Proxy-Prozess im Docker-Image läuft standardmäßig als Root. Für die Ausnutzung sind Administrator-Anmeldedaten für den Proxy erforderlich — also der Master-Schlüssel.
Der Weg zu Cloud-Anmeldedaten
Besondere Aufmerksamkeit verdient ein Mechanismus, für den es keine CVE gibt. Nach Angaben von Wiz erlaubt LiteLLM einem Administrator, durchleitende (Pass-through-)Endpunkte zu erstellen, die Requests an beliebige URLs weiterleiten. Die Ziel-URL wird nicht daraufhin geprüft, ob sie zu privaten Adressbereichen, localhost oder Cloud-Metadatenadressen gehört. Ein Administrator kann die Route auf den Instanz-Metadatenservice zeigen lassen und IAM-Anmeldedaten abrufen. Der Umstieg auf IMDSv2 blockiert diesen Pfad nicht: LiteLLM dokumentiert, dass Header mit dem Präfix x-pass- an den Zielserver ohne dieses Präfix weitergereicht werden, was das Senden der von IMDSv2 geforderten Header ermöglicht. Wiz weist darauf hin, dass diese Funktion „wie vorgesehen arbeitet“, da das Threat Model von LiteLLM Administratoren als vertrauenswürdig betrachtet. Ein Patch ist weder vorhanden noch geplant.
Reale Angriffe: von Kryptomining bis zum Diebstahl von Datenbanken
Die LiteLLM-Schwachstellen werden aktiv ausgenutzt. Nach Angaben von Wiz wurde in ihren Honeypots die Ausnutzung von CVE-2026-42271 zur Installation eines Kryptominers beobachtet. Microsoft veröffentlichte im August die Beschreibung eines Vorfalls, bei dem Angreifer Befehle innerhalb des LiteLLM-Gateway-Prozesses ausführten, den Master-Schlüssel, Provider-Schlüssel und die Datenbank-Verbindungszeichenfolge aus der Container-Umgebung extrahierten und diese anschließend nutzten, um auf PostgreSQL zuzugreifen und Einträge aus den Tabellen für Modelle und virtuelle Schlüssel zu kopieren. Microsoft schätzt mit hoher Zuversicht, dass der Einstiegspunkt der Kette aus CVE-2026-42271 und CVE-2026-48710 entspricht. Das Unternehmen empfiehlt, „AI-Gateways wie Tier-0-Secret-Stores zu behandeln“.
Indikatoren einer Kompromittierung
Laut Wiz wurden in der Kryptominer-Kampagne folgende Indikatoren verwendet:
- IP-Adressen:
185.62.1[.]8,185.84.98[.]85,94.26.106[.]29 - Download-URL:
http://185.62.1.8/mon/mon.zip - Installationspfad des Miners:
/tmp/.dbus-cache/gmon - Pool-Domain:
pool.hashvault[.]pro
Priorisierung der Reaktion
Unter allen beschriebenen Problemen stellen CVE-2026-59822 und CVE-2026-42271 die unmittelbar größte Bedrohung dar — beide werden nachweislich ausgenutzt und betreffen über das Internet erreichbare MCP-Endpunkte. Der Pass-through-Pfad zu Cloud-Metadaten erfordert zuvor erlangten administrativen Zugriff und stellt damit einen Post-Exploitation-Vektor dar, keinen eigenständigen Einstiegspunkt.
Empfehlungen
- Ändern Sie den Master-Schlüssel umgehend von
sk-1234auf einen langen zufälligen Wert. Dies erfordert kein Versionsupdate. Prüfen Sie vor der Änderung, ob ein separater Salt-Schlüssel gesetzt ist — die Prozedur der Rotation unterscheidet sich, und ein Fehler kann dazu führen, dass gespeicherte Anmeldedaten nicht mehr lesbar sind. - Aktualisieren Sie auf Version 1.84.0 oder höher. Diese Version liegt oberhalb der Fix-Schwelle für alle genannten LiteLLM-Schwachstellen, einschließlich CVE-2026-40217, für die der Sicherheitshinweis einen internen Widerspruch zwischen 1.83.10 und 1.83.11 enthält.
- Wenn ein Update nicht sofort möglich ist, blockieren Sie auf Ebene des Reverse Proxy oder API-Gateways:
/mcp/,POST /mcp-rest/test/connection,POST /mcp-rest/test/tools/list,POST /guardrails/test_custom_code. Beschränken SiePOST /guardrailsundPUT /guardrails/{guardrail_id}auf Administratoren. - Beschränken Sie den ausgehenden Netzwerkzugriff des Containers und weisen Sie der Workload nur die minimal notwendige Cloud-IAM-Rolle zu — dies ist der einzige Schutz vor dem Zugriff auf den Instanz-Metadatenservice über Pass-through.
- Bei Verdacht auf eine Kompromittierung: Prüfen Sie die Liste der Guardrails auf fremde Einträge, starten Sie den Prozess neu, um Code aus dem Speicher zu entfernen, und rotieren Sie anschließend Provider-Schlüssel, Master-Schlüssel und Datenbank-Anmeldedaten. Ein Versionsupdate entfernt weder von Angreifern registrierte Guardrails noch hinzugefügte SSH-Schlüssel.
Ein aus dem Internet erreichbares LiteLLM-Gateway mit dem Default-Schlüssel sk-1234 ist faktisch ein offener Secret-Speicher. Die Änderung des Master-Schlüssels ist ein Arbeitsschritt von einer Minute und schließt ohne Versionsupdate die meisten der beschriebenen Angriffsvektoren. Das Update auf 1.84.0 schließt die übrigen. Organisationen, die LiteLLM mit Default-Konfiguration bei sich entdecken, sollten von einer möglichen Kompromittierung ausgehen und alle zugehörigen Secrets rotieren.
