Die Kurzfassung
Fast jedes zehnte offen erreichbare LiteLLM-KI-Gateway akzeptiert noch den dokumentierten Standard-Master-Key sk-1234 – und diese eine Zeichenkette reicht, um das Gateway zu übernehmen und das Cloud-Konto dahinter zu erreichen. Wiz Research hat rund 3.074 aus dem Internet erreichbare LiteLLM-Instanzen untersucht, die im Februar 2026 über Shodan gefunden wurden: 294 davon akzeptierten den Beispielschlüssel aus der LiteLLM-Anleitung, bei 191 war gar kein Master-Key gesetzt – sie nahmen also jeden Wert an. LiteLLM ist das Open-Source-Gateway, das viele Teams zwischen ihre Anwendungen und kostenpflichtige Modellanbieter schalten; der dort hinterlegte Schlüssel öffnet daher jedes nachgelagerte API-Secret.
Die praktische Lesart: Ein KI-Gateway ist kein Entwickler-Komfort, sondern ein Schlüsseltresor mit Netzwerkzugang. Betreibt Ihr Unternehmen eines, gilt dieselbe Disziplin wie für jeden Dienst mit Secrets – eindeutige Schlüssel, keine öffentliche Erreichbarkeit, Cloud-Rollen nach dem Least-Privilege-Prinzip und zeitnahes Patchen. Genau diese Haltung verankern wir von Tag eins an in der Entwicklung von KI-Agenten und Gateways, statt sie nachzurüsten, wenn ein Scan den Standard-Key findet.
Was Wiz gefunden hat
LiteLLM ist ein verbreitetes Open-Source-KI-Gateway – die Software, die ein Unternehmen zwischen die eigenen Anwendungen und die bezahlten Modellanbieter setzt, damit jeder LLM-Aufruf für Routing, Budgetierung, Logging und Schlüsselverwaltung über eine Stelle läuft. Das macht das Gateway bequem und zugleich zu einer Konzentration von Secrets: Es speichert die API-Keys für OpenAI, Anthropic, AWS Bedrock, Google und alles, was das Unternehmen sonst nutzt. Wer das Gateway kontrolliert, kontrolliert sie alle. Da Teams solche Gateways zunehmend beim Aufbau von KI-Agenten und internen Copilots aufsetzen, ist das Gateway still und leise zur Produktionsinfrastruktur geworden – zu genau der Komponente, die unsere Engineers bei jedem KI-Agenten-Projekt als sicherheitskritisch einstufen.
In einem am 10. September 2026 veröffentlichten Bericht beschreibt Wiz Research, wie das Team die aus dem Internet erreichbaren LiteLLM-Installationen gescannt hat. Von rund 3.074 im Februar 2026 auf Shodan gefundenen Instanzen akzeptierten 294 – knapp jede zehnte – sk-1234, den Platzhalter-Master-Key aus der LiteLLM-Dokumentation. In 191 dieser 294 Fälle hatten die Betreiber überhaupt keinen Master-Key gesetzt; das Gateway hätte also jeden beliebigen Wert akzeptiert. Ein späterer Scan im August 2026 zählte Zehntausende weitere Instanzen, viele davon offenbar Wegwerf-Testumgebungen; die Februar-Zahlen sind die konservative, eindeutig exponierte Basis.
Das Unangenehme daran: Es handelt sich nicht um einen exotischen Zero-Day. Es ist ein dokumentiertes Beispiel-Credential, aus einer Installationsanleitung kopiert und nie geändert, auf einem Dienst, der aus dem offenen Internet erreichbar ist. Stand 9. September 2026 zeigte die LiteLLM-Anleitung sk-1234 noch über einem Kommentar, der Betreiber auffordert, den Wert vor dem Echtbetrieb durch einen langen Zufallswert zu ersetzen – ein Hinweis, den nach diesen Zahlen ein spürbarer Teil der Installationen überspringt.
Wie aus einem Standard-Key eine Cloud-Kompromittierung wird
Dass aus einem vergessenen Standardwert ein vollständiger Einbruch wird, liegt daran, dass der LiteLLM-Master-Key zwei Aufgaben zugleich erfüllt. Er ist das Administrator-Credential des Proxys und zugleich das HS256-Geheimnis, mit dem Sitzungstokens signiert werden. Ein Angreifer, der den Schlüssel kennt, meldet sich also nicht nur an – er kann gültige Tokens für jeden Benutzer ausstellen und beliebige Sitzungen im gesamten Gateway fälschen, ganz ohne Konfigurationsänderung. Steht der Schlüssel in öffentlicher Dokumentation, ist dieses „Kennen“ trivial.
Von diesem Admin-Zugang aus ist Wiz die Kette so durchgegangen, wie es ein Angreifer täte. Zuerst gibt das Gateway jeden gespeicherten API-Key der Modellanbieter heraus – die bezahlten Zugangsdaten jedes LLM-Anbieters, bereit zum Missbrauch oder Weiterverkauf. Zweitens, und schlimmer, erreichten die Forscher die Cloud-IAM-Zugangsdaten der Maschine, auf der das Gateway läuft: Pass-Through-Endpunkte ohne URL-Validierung erlauben es, eine Anfrage auf den Cloud-Metadatendienst unter 169.254.169.254 zu richten und temporäre IAM-Zugangsdaten abzuziehen – per Header-Manipulation sogar auf Instanzen, die mit IMDSv2 geschützt sind. Spätestens dann geht es nicht mehr um ein Gateway, sondern um das Cloud-Konto dahinter.
Zwei benannte Schwachstellen schärfen das Bild. CVE-2026-59822 (CVSS 8.8) ist eine Authentifizierungsumgehung in der Model-Context-Protocol-Verarbeitung von LiteLLM: Ein fehlerhafter Fallback behandelt eine Anfrage mit beliebigem Bearer-Token – selbst Authorization: Bearer a – als authentifiziert und gewährt so MCP-Zugriff ohne Anmeldung. Sie wurde am 25. April 2026 in v1.84.0 behoben und nach Ausnutzung in freier Wildbahn in den Known-Exploited-Vulnerabilities-Katalog der CISA aufgenommen. CVE-2026-59821 ist eine Codeausführung nach erfolgreicher Anmeldung: Eigener Guardrail-Code läuft über exec/compile ohne Sandbox, was Wiz nutzte, um Befehle als root auszuführen; behoben am 25. Februar 2026 in v1.82.0. Der Hersteller stuft dieses Guardrail-Problem als gering ein – eine Bewertung, die man gegen eine nachgewiesene Root-Shell abwägen sollte.
Was das für Teams in der DACH-Region bedeutet
Abseits des Produktnamens bleiben drei dauerhafte Lehren. Erstens: Ihr KI-Gateway ist ein Schlüsseltresor – behandeln Sie es auch so. Im Eifer, 2026 Agenten und Copilots auszurollen, haben viele Teams einen LLM-Proxy als „reine Verrohrung“ aufgesetzt und ihm nie das Bedrohungsmodell gegeben, das eine Datenbank bekommt. Dabei hält er jeden Provider-Key und bietet, wie diese Untersuchung zeigt, einen Weg in Ihre Cloud. Dieselbe Secure-by-Default-Haltung wie bei produktiven Datenspeichern – eindeutige Secrets, standardmäßig keine Internet-Erreichbarkeit, minimale Rechte – gehört auf Ihre KI-Schicht und auf die übergreifende Cloud- und DevOps-Plattform, auf der sie läuft.
Zweitens: Standardwerte sind der älteste Einbruch überhaupt, und KI-Infrastruktur hat das gerade neu gelernt. Default-Passwörter und Beispielschlüssel leeren seit Jahrzehnten Server; neu ist nur, dass die verwundbare Kiste ein KI-Gateway ist. Jede Komponente, deren „Getting started“-Anleitung ein wörtliches Credential enthält, braucht eine harte, automatisierte Prüfung, dass der Beispielwert nie in Produktion gelangt – in der CI, in den Deployment-Vorlagen und in regelmäßigen externen Scans dessen, was Sie tatsächlich exponieren.
Drittens: Geleakte Provider-Keys und Cloud-Pivots sind ein Compliance-Ereignis, nicht nur ein Betriebsproblem. Für europäische Teams fallen das unbefugte Abziehen von Zugangsdaten und alle personenbezogenen oder regulierten Daten, die durch das Gateway fließen, klar unter die Erwartungen von DSGVO, NIS2 und DORA an Zugriffskontrolle sowie schnelle, dokumentierte Behebung. Für Teams, die mit US-Kunden aus dem Gesundheits- oder Finanzbereich arbeiten, spiegelt sich dieselbe Exposition in HIPAA- und SOC-2-Pflichten. Zu wissen, welche internen KI-Dienste aus dem Internet erreichbar sind – und belegen zu können, dass sie eindeutige Zugangsdaten und minimale Rechte nutzen –, ist die Kontrolle, nach der Prüfer und Aufsicht zuerst fragen werden.
Was jetzt zu tun ist
- Starken, eindeutigen Master-Key setzen – und Provider-Keys rotieren. Ersetzen Sie
sk-1234oder jeden dokumentierten Beispielwert durch einen langen Zufallswert und rotieren Sie jeden API-Key der Modellanbieter, den das Gateway gespeichert hat – in der Annahme, dass er bereits abgeflossen sein könnte. - LiteLLM auf das aktuelle Release patchen. Aktualisieren Sie über die Fixes für CVE-2026-59822 (v1.84.0) und CVE-2026-59821 (v1.82.0) hinaus und verfolgen Sie die Advisories des Projekts zu den zugehörigen MCP- und Guardrail-Problemen.
- Das Gateway aus dem öffentlichen Internet nehmen. Ein LLM-Proxy sollte nur aus vertrauenswürdigen Subnetzen oder hinter einem VPN bzw. Zero-Trust-Proxy erreichbar sein. Ist öffentlicher Zugriff keine harte Anforderung, entfernen Sie ihn – das allein neutralisiert das Risiko durch Massenscans.
- Den Schadensradius in der Cloud begrenzen. Beschränken Sie den ausgehenden Netzwerkverkehr der Container, damit das Gateway den Metadaten-Endpunkt
169.254.169.254nicht erreicht, vergeben Sie IAM-Rollen nach dem Least-Privilege-Prinzip und bevorzugen Sie eng gefasste Mechanismen wie IRSA statt breiter Instanzrollen. - KI-Infrastruktur in Sicherheitstests aufnehmen. Gateways, Vektordatenbanken und Agenten-Laufzeitumgebungen fehlen routinemäßig in Assessments, obwohl sie die sensibelsten Schlüssel halten. Nehmen Sie sie in Ihren nächsten Penetrationstest auf, prüfen Sie Guardrail-Konfigurationen und starten Sie Prozesse neu, um eingeschleusten Code aus dem Speicher zu entfernen.
Häufig gestellte Fragen
Was hat Wiz bei LiteLLM-Gateways gefunden?
In einem am 10. September 2026 veröffentlichten Bericht hat Wiz Research rund 3.074 aus dem Internet erreichbare LiteLLM-Gateways untersucht, die im Februar 2026 auf Shodan gefunden wurden: 294 – etwa jedes zehnte – akzeptierten sk-1234, den Beispiel-Master-Key aus der LiteLLM-Installationsanleitung. In 191 dieser Fälle war gar kein Master-Key gesetzt, das Gateway hätte also jeden Schlüssel angenommen. Da LiteLLM zwischen Anwendungen und kostenpflichtigen Modellanbietern sitzt, öffnet der Master-Key jedes nachgelagerte Provider-Secret.
Warum ist der LiteLLM-Master-Key so gefährlich?
Der Standard-Master-Key ist zugleich Administrator-Credential und HS256-Geheimnis zum Signieren von Sitzungstokens. Wer das unveränderte sk-1234 kennt, kann beliebige Benutzersitzungen fälschen und ohne Konfigurationsänderung vollen Admin-Zugriff erlangen. Von dort aus zeigte Wiz, wie sich jeder API-Key der Modellanbieter auf dem Server auslesen und über den Instance-Metadata-Service auf die Cloud-IAM-Zugangsdaten des Hosts zugreifen lässt – aus einer geleakten Zeichenkette wird so die Kompromittierung des Cloud-Kontos.
Welche LiteLLM-CVEs sind beteiligt und sind sie gepatcht?
CVE-2026-59822 (CVSS 8.8) ist eine MCP-Authentifizierungsumgehung, bei der jedes Bearer-Token – selbst „Bearer a“ – akzeptiert wird; behoben in v1.84.0 (25. April 2026) und im Known-Exploited-Vulnerabilities-Katalog der CISA gelistet. CVE-2026-59821 ist eine Codeausführung nach Anmeldung über Guardrail-Code ohne Sandbox, behoben in v1.82.0 (25. Februar 2026). Außerdem wurden die zugehörigen Probleme CVE-2026-42271 und CVE-2026-40217 gemeldet. Aktualisieren Sie auf das neueste Release und rotieren Sie die Schlüssel.
Ist ein nicht geänderter Standard-Key nicht nur ein Einrichtungsfehler statt einer Schwachstelle?
Die Sicherheitsrichtlinie von LiteLLM wertet „keinen Master-Key gesetzt“ als Bedienfehler des Betreibers und nicht als Produktfehler, und Stand 9. September 2026 zeigt die Anleitung sk-1234 weiterhin über einem Hinweis, den Wert zu ersetzen. Das Ergebnis ist in beiden Fällen dasselbe: Ein weit verbreitetes Gateway wird mit einem dokumentierten Beispiel-Credential ausgeliefert, das viele Teams nie ändern, und dieser Wert gewährt volle Kontrolle plus Pivot in die Cloud. Die eigentliche Lösung sind sichere Standardeinstellungen und eine harte Prüfung, dass kein Beispiel-Secret in Produktion gelangt.
Was sollten Teams, die LiteLLM betreiben, jetzt tun?
Setzen Sie einen starken, eindeutigen Master-Key, rotieren Sie jeden Provider-Key, den das Gateway gespeichert hatte, und aktualisieren Sie auf das neueste gepatchte Release. Nehmen Sie das Gateway aus dem öffentlichen Internet, sofern es nicht erreichbar sein muss, beschränken Sie den ausgehenden Container-Verkehr, damit der Cloud-Metadaten-Endpunkt nicht erreichbar ist, und vergeben Sie IAM-Rechte minimal. Prüfen Sie Guardrail-Konfigurationen, starten Sie Prozesse neu, um eingeschleusten Code zu entfernen, und halten Sie das KI-Gateway dauerhaft im Scope Ihrer Sicherheitstests.
Quellen
Wiz Research — Off Guard: Breaking LiteLLM from Authentication Bypass to Cloud Compromise
The Hacker News — Nearly 1 in 10 Exposed LiteLLM Gateways Accepted the Example “sk-1234” Admin Key
CISA — Known Exploited Vulnerabilities Catalog