Wiz: Fast jeder zehnte exponierte LiteLLM-Gateway akzeptiert den Beispiel-Admin-Schlüssel sk-1234

Am 9. September 2026 veröffentlichte Wiz Research eine Studie über LiteLLM, das Open-Source-KI-Gateway, das zwischen Anwendungen und den Modellanbietern sitzt, die sie bezahlen, und berichtete, dass 294 der 3.074 LiteLLM-Implementierungen, die im öffentlichen Internet erreichbar waren – 9,6 %, fast jede zehnte – sk-1234, den in der eigenen Einrichtungsdokumentation des Projekts abgedruckten Beispiel-Masterkey, akzeptierten oder überhaupt keine Anmeldedaten verlangten.das AI Incident Archive führt diesen Eintrag neben seinen Nachbarn auf, jeweils mit eigenen Quellen, Schweregrad und Vertrauensgrad.

Das Veröffentlichungsdatum ist das einzige Datum, das der Eintrag trägt, und es ist ein Veröffentlichungsdatum. Der Scan hinter der Schlagzeile wurde im Februar 2026 ausgeführt; die beiden von Wiz beschriebenen Codefehler hatten spätestens Mitte Mai Korrekturen erhalten, in Releases, die die eigenen Aufzeichnungen des Projekts auf März und Mai datieren; die CVE-IDs wurden im Juli vergeben; und der Katalogeintrag erschien im September. Fast alles in dem Bericht war bereits veraltet, als er gedruckt wurde, was einen großen Teil dessen ausmacht, was der Bericht argumentiert.

Die 9,6 % stammen aus einem einzigen Scan, und Wiz sagt, sein eigener Follow-up im August sei damit nicht vergleichbar.

Die Messung ist einfach, und Wiz legt seine Methode offen dar: 3.074 aus dem Internet erreichbare LiteLLM-Proxys, die im Februar 2026 über Shodan gefunden wurden, jeweils darauf geprüft, ob sie sich mit dem dokumentierten Beispielschlüssel authentifizieren würden. Von diesen taten es 294. Innerhalb dieser Gruppe hatten 191 überhaupt keinen Master-Schlüssel konfiguriert und hätten jede ihnen angebotene Zeichenfolge akzeptiert; bei den übrigen war der Platzhalter aus der Einrichtungsanleitung stehen geblieben. Keiner der beiden Fehlermodi setzt einen Softwarefehler voraus. Beide erfordern nur die Adresse des Gateways und den Wert, der in der README des Projekts selbst abgedruckt ist.

Es handelt sich außerdem um den Scan eines einzelnen Anbieters. Wiz’ Zahl wurde am 10. September von der AI Safety Initiative der Cloud Security Alliance und am selben Tag von The Hacker News wiederholt, doch beide geben sie mit Quellenangabe wieder, und für diesen Artikel wurde keine unabhängige Bestätigung der Zahl 3.074 gefunden. Wiz führte im August 2026 einen zweiten Scan durch und fand mehr als 85.000 Instanzen, etwa siebenundzwanzigmal so viele wie im Februar. Das Unternehmen sagt, die meisten davon scheinen Honeypots oder Testumgebungen zu sein, und die beiden Zahlen seien nicht vergleichbar. Es gibt keine aktuelle Expositionskennzahl, und jeder Artikel, der eine nennt, zitiert Februar.

Eine weitere Zahl im Bericht stammt aus Wiz' eigener Telemetrie und nicht aus einem Scan: Das Unternehmen gibt an, LiteLLM sei in etwa einem Drittel der von ihm beobachteten Cloud-Umgebungen vorhanden. Das ist die Sicht eines Anbieters auf seine eigene Kundenbasis und sollte mit Vorsicht behandelt werden, erklärt aber, warum die Forscher eine Gateway-Fehlkonfiguration als Cloud-Problem und nicht als Anwendungsproblem behandelten.

Der Hauptschlüssel ist sowohl die Administrator-Anmeldeinformation als auch der Schalter, der die Authentifizierung einschaltet.

Das Design von LiteLLM gibt einem Geheimnis zwei Aufgaben. Der Hauptschlüssel authentifiziert administrative Anfragen, und seine Existenz ist es, die Authentifizierung überhaupt erst ermöglicht: Ohne Hauptschlüssel und ohne JWT- oder OAuth2-Konfiguration läuft der Proxy offen und akzeptiert jede Anfrage. Wiz ging die Codebasis mit Anthropics Claude Code an und suchte nach Funktionen, die benutzergesteuerte Eingaben entgegennehmen und an einen Ausführungskontext weitergeben, und der Authentifizierungs-Handler war eine von drei Oberflächen, die es kennzeichnete.

Vor v1.82.0-stable war die Folge jenes zweiten Jobs schlimmer als ein offener Proxy. Wiz stellte fest, dass der Auth-Handler, wenn kein Master-Key gesetzt war, jeder eingehenden Anfrage die Rolle PROXY_ADMIN zuwies, sodass ein nicht authentifizierter Aufrufer nicht bloß zugelassen, sondern als Administrator zugelassen wurde. Der im Bericht zitierte Pull Request #22095 änderte die Standardrolle auf INTERNAL_USER und fügte eine Admin-Prüfung zu den Guardrail-Endpunkten hinzu.

Administrativer Zugriff auf ein Gateway ist kein eng begrenztes Privileg. Die Instanz hält einen API-Schlüssel für jeden Anbieter, an den sie weiterleitet, was sie zu einem Ziel für LLMjacking macht – das Ausführen von Modell-Workloads auf Kosten des Opfers. Sie sieht die Prompts und Completions. Sie stellt ausgehende Verbindungen zu MCP-Toolservern her, die in einer internen Bereitstellung wahrscheinlich Issue-Tracker, Chat, Datenbanken und Deployment-Pipelines umfassen.

Wiz hat außerdem einen Weg von dieser administrativen Position zur Cloud-Identität des Hosts aufgezeigt. LiteLLM ermöglicht es einem Administrator, eine Pass-through-Route zu einer beliebigen Ziel-URL zu registrieren, und das Ziel wird nicht gegen private Adressbereiche, localhost oder die Cloud-Metadatenadresse geprüft. Richtet man eine Route auf den Instanz-Metadatendienst, werden die IAM-Anmeldedaten zurückgegeben, unter denen die Workload läuft. Die Umstellung des Metadatendienstes auf IMDSv2, das diese Klasse von Request Forgery normalerweise abwehrt, indem es ein separat bezogenes Sitzungstoken verlangt, hilft nicht: LiteLLM leitet jeden Header mit dem Präfix x-pass- an das Ziel weiter, wobei das Präfix entfernt wird, sodass der Token-Header durchgeschmuggelt werden kann. Wiz sagt, das Feature funktioniere wohl wie vorgesehen unter einem Bedrohungsmodell, das Administratoren vertraut, und bringe daher weder eine CVE noch einen Fix mit sich.

Der letzte Absatz ist eine Demonstration, kein beobachteter Angriff. The Hacker News berichtet am 10. September über die Forschung und gibt an, dass keine Quelle davon berichtet, dass jemand dies gegen eine reale Bereitstellung getan hätte, und dass dafür zunächst Administratorzugriff erforderlich ist. Die Darstellung von Wiz ist dieselbe: Der Pass-through ist eine Designeigenschaft, die erst dann zu einer Sicherheitslücke wird, wenn das Administratorkennwort eine Zeichenfolge aus der Dokumentation ist.

8,8 und 2,1 bewerten dieselbe Kette von unterschiedlichen Ausgangspositionen aus.

Zwei CVEs enthalten die technischen Befunde, und ihre veröffentlichten Scores könnten kaum weiter auseinanderliegen.

CVE-2026-59822 ist die MCP-Authentifizierungsumgehung, und LiteLLMs Sicherheitshinweis stuft sie als High ein, mit 8.8 unter CVSS 4.0, ohne erforderliche Berechtigungen, ohne Benutzerinteraktion und ohne Angriffsvoraussetzungen. Der MCP-Endpunkt verfügt über einen eigenen Authentifizierungs-Handler, der so konzipiert ist, dass er entweder einen LiteLLM-Schlüssel oder ein OAuth2-Token akzeptiert, das für einen vorgelagerten Toolserver bestimmt ist. Wenn ein Token die Validierung von LiteLLM nicht bestand, fing der Handler die 401 ab und ersetzte sie durch ein leeres Authentifizierungsobjekt, anstatt die Anfrage abzulehnen. Jedes Bearer-Token erzeugte daher eine gültige MCP-Sitzung, sogar ein einzelnes Zeichen: Wiz' Proof of Concept sendet ein Bearer-Token aus einem einzigen Buchstaben und erhält eine Sitzungskennung zurück. Der Fehler ist in 1.84.0 behoben.

CVE-2026-59821 ist der Guardrail-Fehler, und der Advisory desselben Projekts bewertet ihn als Low, 2.1, mit erforderlichen hohen Privilegien und gegebenen Angriffsvoraussetzungen. Die Guardrail-Funktion für benutzerdefinierten Code ermöglicht es einem Administrator, Python einzureichen, das der Server kompiliert und ausführt. Der Test-Endpunkt der Web UI validierte den Code gegen eine Liste verbotener Muster und entfernte die Builtins, bevor er ihn ausführte; die Produktions-Endpunkte zum Erstellen und Aktualisieren taten weder das eine noch das andere. Python füllt Builtins wieder auf, wenn sie fehlen, sodass eingereichter Code die Standardbibliothek erreichte. Der Proof of Concept von Wiz registriert eine Guardrail, die zum Zeitpunkt der Registrierung einen Shell-Befehl ausführt – bevor eine Modellanfrage erfolgt – und die Ausgabe des Befehls als Sperrgrund zurückgibt, die in seinem Test als root zurückkam. Der Fehler ist in v1.82.0-stable behoben.

Die beiden Beschreibungen sind miteinander vereinbar, und der Satz, der sie in Einklang bringt, steht im Advisory selbst: LiteLLM merkt an, dass in Bereitstellungen ohne konfigurierten Master-Key Aufrufende als Proxy-Administratoren behandelt werden könnten, was die Guardrail-Endpunkte in Reichweite brachte. Eine 2.1 setzt einen privilegierten Benutzer voraus. Wiz’ Kette beschreibt, was geschieht, wenn der Standardschlüssel jeden Aufrufenden privilegiert. Keine der beiden Bewertungen irrt sich über ihre eigene Ausgangsposition; sie sind sich uneinig darüber, wie oft diese Position frei verfügbar ist.

Ein Vorbehalt gilt für Wiz’ Behauptung, dass ein Angreifer mit dem Standardschlüssel nach 1.82.0 nur Code innerhalb einer Sandbox ausführen konnte. The Hacker News verweist auf eine separate Sicherheitsmitteilung vom Mai 2026, CVE-2026-40217, die beschreibt, wie man in einem Proxy-Prozess, der laut der Mitteilung im Standard-Container-Image als root läuft, durch Bytecode-Techniken in Versionen ab 1.81.8 bis vor 1.83.10 aus dieser Sandbox ausbricht. Um diesen Endpunkt zu erreichen, benötigt man eine Anmeldeinformation für Proxy-Administratoren – und genau das ist der Master-Schlüssel.

Die 8,8 ist ebenfalls nicht allgemeingültig. Die Forschungsnotiz der Cloud Security Alliance stellt fest, dass GitLabs Sicherheitshinweis für dieselbe Schwachstelle einen Basiswert von 8,2 angibt, und weigert sich, zwischen den beiden Methodologien zu entscheiden; sie merkt lediglich an, dass beide im hohen Bereich liegen. Die Einstufung des Eintrags als „hoch“ hängt nicht davon ab, welche Zahl verwendet wird.

Eine CVE wurde in freier Wildbahn ausgenutzt; die Offenlegung des Standardschlüssels hat kein benanntes Opfer.

CISA hat CVE-2026-59822 am 2. September 2026 in den Katalog der bekannten ausgenutzten Schwachstellen (Known Exploited Vulnerabilities) aufgenommen und für zivile Bundesbehörden eine Behebungsfrist bis zum 16. September 2026 gesetzt; der Katalogeintrag enthält CWE-287 und CWE-306, unzureichende Authentifizierung und fehlende Authentifizierung. In der Notiz der Cloud Security Alliance heißt es, Branchen-Tracker hätten sie als erste MCP-spezifische Schwachstelle auf dieser Liste bezeichnet. Wiz hat die beobachtete Ausnutzung veröffentlicht: Ab dem 7. Juli 2026 protokollierten seine Honeypots Anfragen mit Ein-Zeichen-Bearer-Tokens, die Endpunkte zum Auflisten von Modellen sondierten, und Wiz beschreibt keine andere Nutzung der Schwachstelle.

Für den Standardschlüssel existiert nichts Vergleichbares. Es wird kein Opfer genannt, kein Gateway wird als durch sk-1234 übernommen identifiziert, und keine Telemetrie zeigt, dass die 294 Hosts genutzt werden. Der Archiveintrag verzeichnet keinen echten Schaden, was eine Aussage über die Beweislage und nicht über den Mechanismus ist: Die Exposition wurde gemessen, nicht in ihrer Nutzung beobachtet.

Zwei weitere Punkte werden oft zusammen mit diesen abgelegt und sind nicht dasselbe. CVE-2026-42271, Befehlsausführung über zwei MCP-Testendpunkte, ist die LiteLLM-Schwachstelle, die Angreifer tatsächlich genutzt haben, um Code auszuführen; die Honeypots von Wiz verzeichneten, wie darüber ein Kryptominer installiert wurde. Der von Microsoft veröffentlichte Fall vom August 2026, bei dem ein Eindringling die Umgebungsvariablen eines Gateway-Containers auslas, den Hauptschlüssel, die Anbieterschlüssel und eine Datenbank-Verbindungszeichenfolge erbeutete und anschließend Datensätze aus den Modell- und Virtual-Key-Tabellen von LiteLLM kopierte, veranschaulicht, was ein kompromittiertes Gateway wert ist, und nicht einen neuen Einstiegsweg; The Hacker News berichtet, dass Microsoft den Einstiegspunkt als die CVE-2026-42271-Kette bewertet.

Die Position der Maintainer ist, dass ein fehlender Master-Schlüssel ein Einrichtungsfehler und keine Sicherheitslücke ist.

LiteLLMs Sicherheitsrichtlinie ist eindeutig. Sie führt unter den nicht zum Geltungsbereich gehörenden Problemen „Angriffe, die eine Fehlkonfiguration bei der Einrichtung erfordern (z. B. das Nichtsetzen eines master_key in der Proxy-Konfiguration)“ auf und erklärt, dass diese ausdrücklich nicht im Geltungsbereich liegen und nicht als Sicherheitslücke gelten. Wiz kommt von der anderen Seite zu einem kompatiblen Schluss, wenn es das Pass-through-Verhalten als wohl wie beabsichtigt funktionierend bezeichnet.

Diese Position wurde öffentlich auf die Probe gestellt. Am 15. August 2026 reichte ein Forscher GitHub-Issue #37054 ein und meldete, dass ein Proxy mit nicht gesetztem LITELLM_MASTER_KEY jeden beliebigen Schlüsselwert authentifiziert und dass die mitgelieferte docker-compose-Datei keinen setzt. Das Issue wurde 30 Minuten später geschlossen, und der einzige Kommentar dazu stammt vom selben Konto: Er verweist auf die Anweisung der Sicherheitsrichtlinie, dass Meldungen über private Schwachstellenberichte statt über öffentliche Issues erfolgen sollen, entschuldigt sich dafür, öffentlich gemeldet zu haben, und erklärt, dass der vollständige Bericht stattdessen über den Advisory-Weg eingereicht werde. Im Thread erscheint keine Antwort eines Maintainers, sodass die öffentliche Aktenlage zeigt, dass der Melder die öffentliche Meldung zurückzieht, statt dass das Projekt darauf reagiert. Es ist öffentlich nicht dokumentiert, was aus der privaten Einreichung geworden ist.

Für diesen Artikel wurde keine öffentliche Stellungnahme von BerriAI gefunden, in der das Unternehmen seinen Standpunkt zum September-Bericht verteidigt oder überarbeitet. Die sichtbare Reaktion des Unternehmens findet sich in seinen Versionshinweisen und Konfigurationsdateien und nicht in Prosa.

Die Vollstreckung erfolgte am 3. Oktober, vierundzwanzig Tage nach dem Bericht.

Die beiden Codefehler wurden lange vor dem Bericht behoben. Wiz' Offenlegungs-Zeitleiste verzeichnet die Guardrail-Codeausführung, gemeldet am 18. Februar 2026 und behoben am 25. Februar in v1.82.0, den MCP-Bypass, behoben am 25. April in v1.84.0, die beobachtete Ausnutzung am 7. Juli, die am 8. Juli veröffentlichten CVE-IDs und den Katalogeintrag am 2. September. Die Release-Artefakte tragen spätere Daten als die Fixes: Der Paketindex zeigt v1.82.0 am 1. März 2026 und v1.84.0 am 14. Mai, was markiert, wann der jeweilige Fix installierbar wurde, nicht wann er eingeflossen ist. Zwei offizielle Release-Aufzeichnungen datieren dieselben Fixes später als diese Zeitleiste. Der v1.82.0-stable-Release auf GitHub trägt den 11. März 2026, das 1.82.0-Paket auf PyPI den 1. März; v1.84.0 ist auf beiden mit 14. Mai 2026 datiert. Nichts Veröffentlichtes erklärt die Lücke, und für das Argument ist das unerheblich, da jedes dieser Daten Monate vor dem Septemberbericht liegt. Die beiden GitHub-Advisories fügen noch ein drittes Datum hinzu: Sie wurden am 30. Juni 2026 veröffentlicht, drei Wochen vor den CVE-IDs, die laut Wiz am 8. Juli herausgingen.

Was durch keine dieser Releases behoben wurde, war der Standardwert. Wiz berichtete, dass der Master-Key mit Stand 9. September bei der Installation von LiteLLM über Docker Compose oder pip install noch immer auf sk-1234 gesetzt war, und The Hacker News bestätigte, dass die Einrichtungsanleitung an diesem Tag noch diesen Wert verwendete. Die Änderung kam mit v1.104.0, die am 3. Oktober 2026 im Python Package Index hochgeladen wurde und in deren Versionshinweisen sie als Breaking Change aufgeführt ist: Der Proxy verweigert nun den Start, wenn der Master-Key nicht gesetzt, leer oder öffentlich bekannt ist, benennt in der Startfehlermeldung die Quelle des fehlerhaften Werts und gibt einen Befehl aus, der einen sicheren Schlüssel erzeugt. Ein begleitender Eintrag dokumentiert eine Änderung, mit der in mitgelieferten Konfigurationen und Beispielen kein öffentlich bekannter schwacher Master-Key-Wert mehr angegeben wird, und die docker-compose-Datei im Hauptzweig des Projekts legt überhaupt keinen Schlüssel mehr fest.

Das ist die Reihenfolge, die es beizubehalten gilt. Der Code wurde im Frühjahr gepatcht. Der Wert, der diese Patches unzureichend machte, blieb bis Oktober in den Installationsanweisungen, und erst dann begann die Software, ihn abzulehnen. Keine der beiden Korrekturen erforderte, dass die andere wartet.

Was sich nicht geändert hat, ist die Pass-through-Route zum Instanzmetadatendienst. Sie bringt weiterhin keine CVE und keine Behebung mit, weil das Projekt Administratoren als vertrauenswürdig behandelt. Wizs Liste der Abhilfemaßnahmen besteht daher überwiegend aus Betreiberarbeit: ein starker und eindeutiger Master Key, eine Überprüfung der registrierten Guardrails gefolgt von einem Prozessneustart, um im Arbeitsspeicher gehaltenen Code zu löschen, eine Prüfung der Pass-through-Endpunkte mit eingeschränktem Container-Egress und Least-Privilege-IAM-Rollen. Keine dieser vier Maßnahmen lässt sich allein durch ein Upgrade umsetzen.

Was sich aus der Akte nicht ergibt

• Es wurde keine unabhängige Replikation des Scans von 3.074 Hosts gefunden. Die 9,6 % sind Wiz’ Messung, und jede andere Darstellung davon gibt die Zahl lediglich unter Verweis auf die Quelle wieder.

• Es gibt keine aktuelle Expositionszahl. Die Nachuntersuchung im August ergab mehr als 85.000 Instanzen, bei denen es sich laut Wiz größtenteils um Honeypots oder Testbereitstellungen handelt und die nicht mit der Februar-Zählung verglichen werden können.

• Kein Opfer. In den Aufzeichnungen wird kein Gateway, kein Betreiber und kein Cloud-Konto genannt, das durch den Standard-Schlüssel kompromittiert wurde, und die von Wiz dokumentierte Ausnutzung betrifft die MCP-Umgehung und nicht sk-1234.

• Keine Belege dafür, dass die 294 Hosts genutzt wurden. Der Scan prüfte, ob sie sich authentifizieren würden – eine schwächere Aussage als der Nachweis, dass jemand dies tatsächlich getan hat.

• Für die Guardrail-Schwachstelle gibt es keine abschließend festgelegte Schweregradbewertung. Wiz und die Maintainer beschreiben dasselbe Verhalten und bewerten es sehr unterschiedlich; der Unterschied liegt in den Privilegien, von denen jeweils angenommen wird, dass der Angreifer sie bereits besitzt.

Wiz ist außerdem ein Cloud-Sicherheitsanbieter, der Erkennung für diese Art von Exposition verkauft, und der Bericht schließt mit einem Abschnitt darüber, wie die eigenen Produkte LiteLLM-Implementierungen, anfällige Versionen und Shadow-Instanzen identifizieren. Das ist Kontext für die Lektüre des Abschnitts zur Behebung, kein Grund, eine Messung abzutun, deren technische Details durch die eigenen Sicherheitshinweise der Maintainer bestätigt werden.

Der Teil des Datensatzes, der über LiteLLM hinausgelangt, ist der Zeitraum zwischen zwei Datumsangaben. Die Schwachstelle wurde im Frühjahr geschlossen. Die Standardeinstellung, die die Schwachstelle für einen Außenstehenden relevant machte, war im September noch in den Installationsanweisungen abgedruckt, und die Software begann erst im Oktober, sie abzulehnen. Die Betreiber, die die Zeichenkette änderten, mussten auf nichts davon warten.