Fast jeder zehnte exponierte LiteLLM-Gateway akzeptierte den Standard-Admin-Schlüssel

Fast jeder zehnte internetzugängliche LiteLLM-Gateway akzeptierte den Beispiel-Admin-Schlüssel sk-1234 in einem Scan von Wiz Research, und dieser eine Standard-Schlüssel öffnet den Zugang zu gespeicherten Provider-API-Schlüsseln und in den Tests von Wiz zu den Cloud-Identitätsanmeldeinformationen der Maschine, auf der der Gateway läuft. LiteLLM ist ein Open-Source-KI-Gateway, die Software, die ein Unternehmen zwischen seine Anwendungen und die Modellanbieter, für die es bezahlt, platziert. Der Master-Schlüssel ist die Administrator-Anmeldeinformation des Gateways, und wer ihn besitzt, kann jeden auf dem Server gespeicherten API-Schlüssel eines Modellanbieters lesen.

Wiz Research führte einen Scan durch und fand im Februar 3.074 LiteLLM-Gateways auf Shodan, einer Suchmaschine für internetzugängliche Systeme. Von diesen akzeptierten 294 sk-1234. Bei 191 davon war überhaupt kein Schlüssel gesetzt, sodass sie jeden Wert akzeptiert hätten, während beim Rest der Beispielwert aus der Einrichtungsanleitung beibehalten wurde. Ein zweiter Scan im August lokalisierte mehr als 85.000 Instanzen, aber Wiz sagt, die meisten scheinen Honeypots oder Testsysteme zu sein, sodass die beiden Zählungen nicht verglichen werden können und es keine aktuelle Zahl gibt. Stand 9. September verwendet die Einrichtungsanleitung von LiteLLM immer noch sk-1234 über einem Kommentar, der Betreiber auffordert, ihn vor dem echten Einsatz durch einen langen Zufallswert zu ersetzen.

Der Grund, warum ein Schlüssel so viel bedeutet, ist, dass der Master-Schlüssel zwei Aufgaben gleichzeitig erfüllt. Er ist sowohl die Admin-Anmeldeinformation als auch der Schalter, der die Authentifizierung aktiviert. Vor Version 1.82.0-stable gewährte ein Gateway, das ohne Master-Schlüssel gestartet wurde, jeder eingehenden Anfrage volle Admin-Rechte. Ein Admin auf einem dieser Server hat viel in Reichweite: Der Gateway kann einen API-Schlüssel für jeden Anbieter speichern, an den er weiterleitet, kann jeden Prompt und jede Antwort sehen, die durchlaufen, und kann sich über das Model Context Protocol (MCP), die Schnittstelle, die es dem Gateway ermöglicht, mit internen Diensten zu sprechen, mit internen Tools verbinden. Er läuft normalerweise auch mit den Cloud-Berechtigungen der Workload, in der er bereitgestellt ist. Allein gestohlene Provider-Schlüssel ermöglichen es einem Angreifer, Modell-Workloads auf Kosten des Opfers auszuführen, ein Missbrauch, der als LLMjacking bekannt ist.

Wiz zeigte auch, wie der Schlüssel das Cloud-Konto erreichen kann. LiteLLM ermöglicht es einem Administrator, einen Pass-Through-Endpunkt zu erstellen, eine Route, die Anfragen an jede vom Admin gewählte URL weiterleitet. Die Ziel-URL wird nicht gegen private Adressbereiche, localhost oder Cloud-Metadaten-Adressen geprüft. Ein Admin kann daher eine Route auf den Instanz-Metadatendienst zeigen lassen und die zurückgegebenen IAM-Anmeldeinformationen auslesen. Der Wechsel zu IMDSv2, einer neueren Methode zum Anfordern von Metadaten, verhindert dies nicht. LiteLLM dokumentiert, dass jeder mit einem x-pass--Präfix gesendete Header mit entferntem Präfix an das Ziel weitergegeben wird, und Wiz nutzte dieses Verhalten, um die von IMDSv2 benötigten Header zu senden. Keine Quelle berichtet, dass jemand dies gegen eine echte Bereitstellung getan hat. Es ist eine Demonstration und erfordert zuerst Admin-Zugriff. Wiz sagt, die Funktion arbeite wohl wie beabsichtigt, da das Bedrohungsmodell von LiteLLM Administratoren als vertrauenswürdig behandelt, sodass es keine CVE und keinen Fix gibt. Die veröffentlichte Sicherheitsrichtlinie von LiteLLM besagt, dass Angriffe, die einen Einrichtungsfehler erfordern, wie das Nicht-Setzen eines Master-Schlüssels, ausdrücklich nicht im Geltungsbereich liegen und nicht als Schwachstellen behandelt werden.

Der einzige Code-Ausführungsfehler im Bericht von Wiz ist CVE-2026-59821, und Forscher und Maintainer beschreiben ihn sehr unterschiedlich. Wiz nennt ihn Post-Authentifizierungs-Code-Ausführung auf Root-Ebene und zeigt einen Test, der uid=0(root) im Gateway-Container zurückgibt. Der Advisory von LiteLLM für dieselbe CVE bewertet ihn als Niedrig mit 2,1 auf der CVSS-Skala und beschreibt einen Fehler, der ein hochprivilegiertes Konto erfordert. Beide beschreiben dasselbe Verhalten. Vor 1.82.0-stable übersprangen die Endpunkte, die benutzerdefinierte Code-Guardrails erstellen und aktualisieren, die Sandbox- und Musterprüfungen, die der Test-Endpunkt anwendete, sodass jeder, der sie erreichen konnte, Python einreichen konnte, das im Container ausgeführt wurde. Der Advisory fügt hinzu, dass eine Bereitstellung ohne Master-Schlüssel Aufrufer als Proxy-Administratoren behandelte, was diese Endpunkte in Reichweite brachte. Der Bericht von Wiz stellt fest, dass nach 1.82.0 ein Angreifer mit dem Standard-Schlüssel nur Code innerhalb einer Sandbox ausführen konnte, aber die eigene Aufzeichnung von LiteLLM unterstützt dies nicht für jede Version. Ein separater Advisory, der im Mai veröffentlicht wurde, CVE-2026-40217, besagt, dass die Sandbox mit Bytecode-Techniken umgangen werden konnte, indem Code im Proxy-Prozess ausgeführt wird, dem Hauptprogramm, das den Datenverkehr abwickelt, das laut Advisory im Standard-Docker-Image als Root läuft. Er deckt Versionen von 1.81.8 bis einschließlich 1.83.10 ab, und das Erreichen des Endpunkts erfordert eine Proxy-Admin-Anmeldeinformation, die der Master-Schlüssel ist. Beide von Wiz gemeldeten Fehler wurden Monate vor seinem Bericht vom 9. September behoben, im Februar und April, und ihre CVEs wurden im Juli veröffentlicht.

Separat werden ältere LiteLLM-Probleme bereits ausgenutzt. CISA fügte CVE-2026-59822 am 2. September seinem Katalog bekannter ausgenutzter Schwachstellen hinzu. Der Fehler, ebenfalls von Wiz gefunden, hat einen CVSS-Score von 8,8 und ermöglicht es einem nicht authentifizierten Angreifer, eine gültige MCP-Sitzung mit einem beliebigen Bearer-Token zu öffnen, einschließlich eines mit nur einem Zeichen. Bundesbehörden haben bis zum 16. September Zeit, ihn zu beheben. Wiz sah ihn ab dem 7. Juli gegen seine eigenen Honeypots eingesetzt, in Anfragen mit Ein-Zeichen-Tokens, um Modelllistungs-Endpunkte zu sondieren, und beschrieb keine andere Verwendung. Dieser Fehler erreicht nicht die oben genannten Code-Ausführungs- oder Anmeldeinformationspfade. Wiz stellt fest, dass er nur MCP-Server-Zugriff ermöglicht, und was er erreichen kann, hängt davon ab, welche Tool-Server eine Organisation verbunden hat.

Der LiteLLM-Fehler, den Angreifer zum Ausführen von Code verwendet haben, ist ein anderer. CVE-2026-42271 hat einen CVSS-Score von 8,7 und ermöglichte es jedem authentifizierten Benutzer, Befehle auf dem Host über zwei MCP-Test-Endpunkte auszuführen. Horizon3.ai berichtete im Juni, dass er mit einem Starlette-Host-Header-Fehler, CVE-2026-48710, verkettet werden konnte, um dasselbe ganz ohne Anmeldeinformationen zu tun. Die Honeypots von Wiz zeichneten auf, dass dieser Fehler verwendet wurde, um einen Kryptowährungs-Miner zu installieren. Microsoft veröffentlichte im August einen Fall, in dem Angreifer Befehle innerhalb eines LiteLLM-Gateway-Prozesses ausführten, die Umgebung des Containers nach dem Master-Schlüssel, den Provider-Schlüsseln und der Datenbankverbindungszeichenfolge lasen und dann diese Zeichenfolge verwendeten, um auf den zugrunde liegenden relationalen Datenbankserver zuzugreifen und Datensätze aus den Modell- und virtuellen Schlüsseltabellen von LiteLLM zu kopieren. Microsoft schätzt mit hoher Zuversicht, dass die Angreifer Zugang über den exponierten Gateway erhielten, und sagt, der Einstiegspunkt passe zur Kette CVE-2026-42271 und CVE-2026-48710. Das Unternehmen fügte hinzu: „Behandeln Sie KI-Gateways als Tier-0-Geheimnisspeicher.“

Ein Upgrade auf LiteLLM 1.84.0 oder höher deckt jeden Fehler in der Tabelle ab. CVE-2026-59822 ist in 1.84.0 behoben. CVE-2026-42271 ist in 1.83.7 behoben. CVE-2026-59821 ist in 1.82.0-stable behoben. CVE-2026-40217 ist in 1.83.10 behoben, obwohl der Advisory-Text von LiteLLM auf 1.83.11 verweist. Der erste praktische Schritt ist, den Master-Schlüssel von sk-1234 auf einen langen Zufallswert zu ändern. Dies erfordert kein Upgrade und schließt jeden Pfad im Bericht von Wiz, der vom Besitz des Schlüssels abhängt. Bevor Sie den Schlüssel rotieren, prüfen Sie, ob ein separater Salt-Schlüssel gesetzt ist, da das Rotationsverfahren unterschiedlich ist und die Verwendung des falschen gespeicherte Anmeldeinformationen unlesbar machen kann. Wenn Sie noch nicht upgraden können, blockieren Sie /mcp/ und die beiden MCP-Test-Endpunkte POST /mcp-rest/test/connection und POST /mcp-rest/test/tools/list an Ihrem Reverse-Proxy oder API-Gateway. Blockieren Sie auch POST /guardrails/test_custom_code und beschränken Sie POST /guardrails und PUT /guardrails/{guardrail_id} auf Administratoren. Dies sind die Workarounds in den eigenen Advisories von LiteLLM. Überprüfen Sie die Pass-Through-Endpunkte auf dem Gateway, beschränken Sie den ausgehenden Netzwerkzugriff des Containers und geben Sie der Workload die engste Cloud-IAM-Rolle, mit der sie arbeiten kann. Wenn Sie glauben, dass ein Angreifer Zugriff gehabt haben könnte, überprüfen Sie die Guardrails-Liste auf Einträge, die Sie nicht erstellt haben, und starten Sie den Prozess neu, um im Speicher gehaltenen Code zu löschen, und rotieren Sie dann die Provider-Schlüssel, den Master-Schlüssel und die Datenbank-Anmeldeinformationen. Ein Upgrade entfernt weder eine von einem Angreifer registrierte Guardrail noch einen von ihm hinzugefügten SSH-Schlüssel.

Es gibt keinen Patch für die Pass-Through-Route zu Instanz-Metadaten, da LiteLLM sie nicht als Fehler behandelt. Ausgehende Netzwerkbeschränkungen und enge IAM-Rollen sind die einzigen verfügbaren Kontrollen. Keine Quelle legt dar, wie man prüft, ob MCP- oder Pass-Through-Routen auf einem übernommenen Gateway aktiviert sind. Die Jagdabfragen von Microsoft finden Ausnutzung, nicht Konfiguration. Für Website-Besitzer und IT-Teams, die Dienste wie diesen in ihrer eigenen Infrastruktur betreiben, bietet AEU-I sicherheitsorientierte IT-, Infrastruktur- und Beratungsdienstleistungen an, um exponierte Gateways zu überprüfen und Cloud-Berechtigungen so eng wie möglich zu halten.