LiteLLM-Gateways offen im Netz: Fast jedes zehnte akzeptiert sk-1234
Eine Untersuchung von Wiz zeigt ein grundlegendes Betriebsrisiko bei öffentlich erreichbaren LiteLLM-Gateways: 294 von 3.074 geprüften Instanzen akzeptierten den dokumentierten Beispielschlüssel sk-1234 oder waren ohne gesetzten Master Key offen. Admins sollten Exposition, Schlüssel, Version und privilegierte Funktionen sofort prüfen.
Bei einer Internetmessung von Wiz akzeptierten 294 von 3.074 öffentlich erreichbaren LiteLLM-Gateways den Beispielschlüssel sk-1234 oder arbeiteten ohne gesetzten Master Key. Das entspricht 9,6 Prozent der im Februar 2026 über Shodan ermittelten Instanzen. In 191 der 294 Fälle war laut Wiz überhaupt kein Master Key konfiguriert. Solche Gateways behandelten eingehende Anfragen in älteren Versionen faktisch wie administrative Zugriffe.
Die neue Meldung ist vor allem eine Warnung vor unsicherem Betrieb. LiteLLM sitzt als zentraler Vermittler zwischen Anwendungen und kostenpflichtigen KI-Anbietern. Das Gateway verwaltet deshalb häufig Provider-Schlüssel, Prompts, Antworten, Budgets, virtuelle Schlüssel und Verbindungen zu internen Werkzeugen. Ein öffentlich erreichbarer Admin-Zugang kann damit weit mehr offenlegen als nur ein einzelnes Modellkonto. Zusätzlich verschärfen zwei bereits behobene Schwachstellen das Risiko veralteter Installationen: CVE-2026-59822 umgeht die MCP-Authentifizierung, CVE-2026-59821 ermöglicht über Custom Code Guardrails Codeausführung im Gateway-Container.
Internetmessung zeigt konkretes Betriebsproblem
Wiz identifizierte im Februar 3.074 LiteLLM-Gateways, die aus dem öffentlichen Internet erreichbar waren. 294 davon akzeptierten sk-1234, den Beispielwert aus der LiteLLM-Einrichtungsdokumentation. Die Zahl umfasst sowohl Systeme mit diesem unveränderten Schlüssel als auch 191 Instanzen, auf denen kein Master Key gesetzt war. Der Wert ist eine Momentaufnahme und keine Hochrechnung auf alle LiteLLM-Installationen.
Eine weitere Suche im August lieferte mehr als 85.000 Treffer. Wiz warnt jedoch davor, beide Zahlen direkt zu vergleichen, weil ein erheblicher Teil der späteren Treffer vermutlich aus Honeypots oder Testsystemen bestand. Für die Risikobewertung reicht der belastbare Februar-Befund: Hunderte erkennbare Gateways waren mit einem öffentlich dokumentierten Beispielwert oder ohne wirksame Zugangskontrolle erreichbar.
Der Master Key hat eine besonders kritische Rolle. Er dient nicht nur als Zugangsdatenbestandteil, sondern schaltet bei älteren Bereitstellungen zugleich die Authentifizierung ein. Vor Version 1.82.0-stable konnten Instanzen ohne gesetzten Master Key Anfragen mit administrativen Rechten behandeln. Ein Angreifer mit Admin-Rechten kann gespeicherte Schlüssel zu Modellanbietern auslesen und kostenpflichtige Anfragen auf fremde Rechnung ausführen. Dieses als LLMjacking bezeichnete Missbrauchsszenario kann hohe Kosten erzeugen und zugleich sensible Inhalte offenlegen.
Drei Risiken müssen getrennt bewertet werden
Default-Key, MCP-Bypass und Guardrail-RCE sind keine drei Namen für denselben Fehler. Sie haben unterschiedliche Voraussetzungen und müssen im Betrieb separat geprüft werden. Gemeinsam ist ihnen, dass Internetexposition und übermäßige Rechte ihre Auswirkungen deutlich vergrößern.
| Problem | Voraussetzung | Mögliche Folge | Abhilfe |
|---|---|---|---|
sk-1234 oder kein Master Key | Gateway öffentlich erreichbar, Beispielwert unverändert oder Authentifizierung nicht aktiviert | Administrativer Zugriff, Provider-Schlüssel, Prompts, Budgets und Konfigurationen gefährdet | Langen zufälligen Master Key setzen, rotieren, Zugang auf vertrauenswürdige Netze begrenzen |
| CVE-2026-59822 | LiteLLM vor 1.84.0, erreichbarer MCP-Endpunkt | Beliebiger Bearer-Token kann eine gültige MCP-Sitzung eröffnen und freigegebene Werkzeuge erreichen | Auf mindestens 1.84.0 aktualisieren, MCP-Freigaben und Protokolle prüfen |
| CVE-2026-59821 | Version vor 1.82.0-stable, Zugriff auf privilegierte Guardrail-Verwaltung | Eingeschleuster Python-Code läuft im Gateway-Container, im Standardbild laut Wiz als root | Aktualisieren, Custom Code Guardrails prüfen, Containerrechte reduzieren |
Diese Trennung verhindert falsche Entwarnung. Ein aktueller Patch beseitigt keinen schwachen Master Key. Ein starker Master Key ersetzt umgekehrt kein Update gegen einen Authentifizierungsfehler. Ebenso ist eine nicht öffentlich erreichbare Instanz nicht automatisch sicher, wenn viele interne Nutzer oder kompromittierte Dienste auf privilegierte Endpunkte zugreifen können.
CVE-2026-59822 umgeht die MCP-Authentifizierung
CVE-2026-59822 betrifft LiteLLM-Versionen vor 1.84.0 und wird mit CVSS 8.8 bewertet. Nach der Analyse von Wiz erzeugte der MCP-Endpunkt auch dann eine authentifizierte Sitzung, wenn die normale Prüfung eines übergebenen Bearer-Tokens mit HTTP 401 oder 403 scheiterte. Dadurch genügte ein ungültiger Token, um eine MCP-Sitzung aufzubauen.
Die konkrete Auswirkung hängt von den angeschlossenen MCP-Servern und deren Freigaben ab. Sind dort Datenbankabfragen, Dateizugriffe, GitHub, Jira, Slack, Kalender, interne Wissensbestände oder CI/CD-Werkzeuge erreichbar, kann der Bypass diese Funktionen einem nicht autorisierten Nutzer zugänglich machen. Besonders kritisch ist die Option allow_all_keys, wenn damit Werkzeuge für sämtliche Schlüssel freigegeben wurden.
CISA nahm CVE-2026-59822 am 2. September 2026 in den Known Exploited Vulnerabilities Catalog auf. Wiz beobachtete seit dem 7. Juli Anfragen gegen eigene Honeypots, bei denen Ein-Zeichen-Tokens verwendet wurden. Diese Beobachtung belegt aktive Ausnutzung des Authentifizierungsfehlers. Sie belegt nicht automatisch, dass die unten beschriebenen Cloud- oder Root-Szenarien über denselben Weg erreicht wurden. Der MCP-Bypass muss deshalb eigenständig bewertet werden.
CVE-2026-59821: Codeausführung über Custom Code Guardrails
CVE-2026-59821 betrifft Versionen vor 1.82.0-stable. LiteLLM erlaubt Administratoren, eigene Python-Logik als Custom Code Guardrail vor oder nach Modellaufrufen auszuführen. Laut Wiz wandten die Endpunkte zum Erstellen und Aktualisieren solcher Guardrails die Schutzprüfungen des Testendpunkts nicht korrekt an. Eingereichter Code konnte dadurch mit den Rechten des Gateway-Prozesses laufen.
Wiz demonstrierte die Ausführung als uid=0(root) im Gateway-Container. Das LiteLLM-Advisory bewertet den Fehler zugleich nur mit CVSS 2.1, weil ein hoch privilegierter Zugang erforderlich ist. Beide Aussagen widersprechen sich nicht zwingend: Die mögliche technische Wirkung ist hoch, der direkte Angriffsweg setzt jedoch normalerweise Admin-Rechte voraus. Gefährlich wird die Kombination mit einem unveränderten Master Key oder einer Installation ohne Authentifizierung, weil eine Fehlkonfiguration diese Voraussetzung praktisch beseitigen kann.
Admins sollten außerdem Container-root nicht automatisch mit root auf dem Host gleichsetzen. Die Reichweite hängt von Mounts, Linux-Capabilities, Docker-Socket, Netzwerkzugriff, Service-Account, Cloud-IAM-Rolle und Laufzeitkonfiguration ab. Ein minimal berechtigter Container begrenzt Folgeschäden. Ein Gateway mit gemountetem Docker-Socket, weitreichender Cloud-Rolle oder Zugriff auf interne Verwaltungsnetze kann dagegen zum Sprungbrett werden.
Warum der Adminzugang bis in die Cloud reichen kann
Wiz beschreibt zusätzlich eine administrative Pass-through-Funktion, die Anfragen an frei wählbare Ziele weiterleiten kann. Private Adressbereiche, localhost und Cloud-Metadatenziele wurden dabei nicht grundsätzlich blockiert. Mit bereits erlangten Admin-Rechten ließ sich in Tests ein Ziel auf den Metadatendienst einer Cloud-Instanz setzen und dessen IAM-Zugangsdaten abrufen.
Auch IMDSv2 war in der demonstrierten Konfiguration kein ausreichender Schutz, weil LiteLLM bestimmte Client-Header mit einem Präfix an das Ziel weiterleiten kann. Wiz stuft die Pass-through-Funktion selbst nicht als eigenständige Schwachstelle ein, da das LiteLLM-Bedrohungsmodell Administratoren vertraut. Der Befund zeigt aber, warum ein schwacher Master Key nicht als kleines Konfigurationsproblem behandelt werden darf. Er kann den Übergang vom KI-Gateway zu Cloud-Berechtigungen ermöglichen.
Für Produktionssysteme folgt daraus ein klares Prinzip: Ein KI-Gateway ist ein Tier-0-Geheimnisspeicher. Sein Admin-Zugang verdient mindestens denselben Schutz wie ein Secret Manager, eine CI/CD-Steuerung oder ein Cloud-Verwaltungskonto. Öffentliche Erreichbarkeit sollte eine begründete Ausnahme sein, nicht der Ausgangszustand.
Was Admins jetzt prüfen sollten
- Internetexposition erfassen: DNS, Firewall, Load Balancer, Reverse Proxy, Kubernetes Ingress und Cloud Security Groups auf öffentlich erreichbare LiteLLM-Endpunkte prüfen.
- Master Key kontrollieren: Sicherstellen, dass ein langer zufälliger Wert gesetzt ist.
sk-1234, leere Werte und wiederverwendete Testschlüssel sofort ersetzen. - Geheimnisse rotieren: Bei möglicher Exposition nicht nur den Master Key, sondern auch Provider-API-Schlüssel, virtuelle Schlüssel, Datenbankkennwörter und Cloud-Zugangsdaten austauschen.
- Version aktualisieren: Mindestens LiteLLM 1.84.0 einsetzen, damit CVE-2026-59822 sowie die hier genannten älteren Fehler abgedeckt sind.
- MCP-Inventar erstellen: Alle verbundenen MCP-Server, angebotenen Werkzeuge und Datenquellen dokumentieren. Nicht benötigte Integrationen deaktivieren.
- Freigaben begrenzen:
allow_all_keysund pauschale Werkzeugfreigaben entfernen, sofern sie nicht zwingend erforderlich und anderweitig abgesichert sind. - Guardrails prüfen: Custom Code Guardrails inventarisieren, unbekannte oder nachträglich veränderte Einträge untersuchen und privilegierte Verwaltungsrechte einschränken.
- Container härten: Als nicht privilegierter Nutzer starten, unnötige Capabilities entfernen, Dateisysteme möglichst schreibgeschützt einbinden und den Docker-Socket nicht mounten.
- Cloud-Rechte reduzieren: Dem Workload nur die erforderlichen IAM-Berechtigungen geben und Metadatenzugriffe zusätzlich per Netzwerk- und Plattformrichtlinie begrenzen.
- Protokolle auswerten: Fehlgeschlagene und ungewöhnlich kurze Bearer-Tokens, MCP-Sitzungsaufbauten, Änderungen an Guardrails, neue Pass-through-Routen und unerwartete Modellkosten untersuchen.
- Netzzugang beschränken: Admin- und MCP-Endpunkte über VPN, private Netze, mTLS oder einen vorgeschalteten Identity-Proxy absichern.
- Vorfallgrenze festlegen: Wenn das Gateway mit Default-Key erreichbar war, den Zustand als mögliche Kompromittierung behandeln und nicht nur den Schlüssel ändern.
Einordnung für kleine Unternehmen
Für kleinere IT-Teams ist die wichtigste Maßnahme kein komplexes neues Sicherheitsprodukt. Zuerst muss geklärt werden, ob LiteLLM überhaupt direkt aus dem Internet erreichbar sein muss. Viele interne Anwendungen benötigen nur privaten Zugriff. Eine Firewallregel oder ein privater Ingress reduziert die Angriffsfläche sofort, ersetzt aber weder Schlüsselrotation noch Updates.
Wer LiteLLM per Docker betreibt, sollte Konfiguration und Laufzeit gemeinsam prüfen. Die grundlegende Bereitstellung beschreibt die S-EDV-Einordnung zum LiteLLM-Docker-Gateway. Bereits bekannte aktive Angriffe über andere MCP-Schwachstellen behandelt der Beitrag zu CVE-2026-42271 und CISA KEV. Der aktuelle Fall hat jedoch einen anderen Schwerpunkt: Er zeigt, wie unsichere Veröffentlichung, Beispielschlüssel und fehlende Admin-Kontrollen vorhandene Sicherheitslücken erst in eine unmittelbar erreichbare Angriffskette verwandeln.
Die Untersuchung ist auch vom früheren LiteLLM-Supply-Chain-Fall abzugrenzen. Dort stand die Integrität von Paketen und CI-Prozessen im Mittelpunkt. Hier geht es um den laufenden Gateway-Dienst, seine Erreichbarkeit, den Master Key und privilegierte Konfigurationsfunktionen. Entsprechend unterscheiden sich die Kontrollen: Netzgrenzen, Secrets-Rotation, Versionsprüfung, MCP-Inventar und Admin-Audit stehen jetzt an erster Stelle.
Passende Anleitungen auf S-EDV
- LiteLLM als Docker-Gateway betreiben: Grundlagen zur Bereitstellung und Einordnung des zentralen KI-Proxys.
- LiteLLM: CVE-2026-42271 aktiv ausgenutzt: Hintergrund zur separaten MCP-RCE und zum CISA-KEV-Eintrag.
- LiteLLM-Supply-Chain-Angriff: Kontrollen für API-Schlüssel, Pakete und CI-Umgebungen.
