{"id":51765,"date":"2026-09-10T11:37:57","date_gmt":"2026-09-10T09:37:57","guid":{"rendered":"https:\/\/overcentral.com\/de\/?p=51765"},"modified":"2026-09-10T11:37:57","modified_gmt":"2026-09-10T09:37:57","slug":"litellm-gateway-standard-admin-schluessel-sk-1234-51765","status":"publish","type":"post","link":"https:\/\/overcentral.com\/de\/litellm-gateway-standard-admin-schluessel-sk-1234-51765\/","title":{"rendered":"Fast jedes zehnte LiteLLM-Gateway akzeptiert Standard-Admin-Schl\u00fcssel sk-1234"},"content":{"rendered":"

Fast jedes zehnte LiteLLM<\/a>-Gateway, das \u00fcber das Internet erreichbar ist, akzeptiert den Standard-Administrator-Schl\u00fcssel sk-1234<\/strong>. Diesen Wert listet die offizielle Setup-Anleitung des Open-Source-KI-Gateways als Beispiel. Unternehmen setzen LiteLLM als Vermittler zwischen ihren Anwendungen und den von ihnen bezahlten KI-Modell<\/a>aaaa-Anbietern ein. Wer \u00fcber diesen Schl\u00fcssel verf\u00fcgt, kann s\u00e4mtliche API-Keys der Modellanbieter auf dem Server auslesen. In Tests der Sicherheitsfirma Wiz Research<\/a> gelang damit sogar der Zugriff auf die Cloud-IAM-Anmeldeinformationen der zugrunde liegenden Maschine. Ein Austausch des Schl\u00fcssels erfordert kein Upgrade und schlie\u00dft s\u00e4mtliche Angriffspfade, die von seiner Kenntnis abh\u00e4ngen.<\/p>\n

Die Zahlenbasis der Untersuchung<\/h2>\n

Wiz f\u00fchrte im Februar einen einzelnen Scan durch und identifizierte 3.074 LiteLLM-Gateways auf der Suchmaschine Shodan. Von diesen akzeptierten 294 den Standardschl\u00fcssel. Bei 191 dieser 294 Systeme war \u00fcberhaupt kein Schl\u00fcssel gesetzt, sodass sie jede Anfrage akzeptiert h\u00e4tten. Bei den restlichen Systemen war der Beispielwert aus der Anleitung unver\u00e4ndert hinterlegt. Ein zweiter Scan im August entdeckte \u00fcber 85.000 Instanzen, doch Wiz zufolge handelt es sich bei den meisten um Honeypots oder Testsysteme, weshalb die Zahlen nicht vergleichbar sind. Eine aktuelle Zahl existiert nicht. Die Setup-Anleitung von LiteLLM verwendet noch immer sk-1234<\/code>codecodecodecodecode \u2013 oberhalb eines Kommentars, der Betreiber auffordert, diesen vor dem produktiven Einsatz durch einen langen, zuf\u00e4lligen Wert zu ersetzen.<\/p>\n

Warum ein einziger Schl\u00fcssel derart schwerwiegend ist<\/h2>\n

Der Masterschl\u00fcssel \u00fcbernimmt gleich zwei Aufgaben, was einen voreingestellten Wert so kritisch macht: Er dient als Admin-Anmeldedaten und schaltet die Authentifizierung frei. In Versionen vor 1.82.0-stable gew\u00e4hrte ein Gateway ohne gesetzten Masterschl\u00fcssel jeder eingehenden Anfrage vollst\u00e4ndige Admin-Rechte. Ein Administrator auf einem solchen Server hat weitreichende M\u00f6glichkeiten: Das Gateway kann API-Keys f\u00fcr alle angebundenen Anbieter speichern, s\u00e4mtliche Prompts und Antworten einsehen und \u00fcber das Model Context Protocol (MCP) Verbindung zu internen Tools aufnehmen. Da es zudem meist mit den Cloud-Berechtigungen der eingesetzten Workload l\u00e4uft, erm\u00f6glichten gestohlene Provider-Keys einem Angreifer, Modell-Workloads auf Kosten des Opfers auszuf\u00fchren \u2013 ein Missbrauch, der als LLMjacking bekannt ist.<\/p>\n

Der Weg zum Cloud-Konto<\/h2>\n

LiteLLM erlaubt Administratoren die Einrichtung eines Durchgangs-Endpunkts, einer Route, die Anfragen an jede vom Admin gew\u00e4hlte URL weiterleitet. Die Ziel-URL wird nicht auf private Adressbereiche, Localhost oder Cloud-Metadaten-Adressen gepr\u00fcft. Ein Admin kann daher eine Route auf den Metadaten-Dienst der Instanz leiten und die zur\u00fcckgegebenen IAM-Anmeldeinformationen auslesen. Der Wechsel zu IMDSv2 verhindert dies nicht: LiteLLM dokumentiert, dass jeder Header mit dem Pr\u00e4fix x-pass-<\/code>codecodecodecodecode an das Ziel weitergeleitet wird (wobei das Pr\u00e4fix entfernt wird), und Wiz nutzte dies, um die f\u00fcr IMDSv2 erforderlichen Header zu senden. Es gibt keine Berichte, dass dies gegen eine reale Installation eingesetzt wurde; es handelt sich um eine Demonstration, die zun\u00e4chst Admin-Zugriff erfordert. Wiz stellt fest, dass diese Funktion im Grunde wie vorgesehen funktioniert, da das Bedrohungsmodell von LiteLLM Administratoren als vertrauensw\u00fcrdig einstuft. Es gibt weder eine CVE noch einen Fix. Das Projekt selbst vertritt eine \u00e4hnliche Position: Seine ver\u00f6ffentlichte Sicherheitsrichtlinie listet Angriffe, die auf einen Einrichtungsfehler (wie das Fehlen eines Masterschl\u00fcssels) angewiesen sind, als \u201eexplizit nicht im Rahmen“ und damit nicht als Schwachstellen.<\/p>\n

Die Guardrail-Schwachstelle und ein umstrittener Schweregrad<\/h2>\n

Die einzige Schwachstelle zur Codeausf\u00fchrung in Wiz‘ Bericht ist CVE-2026-59821<\/strong>. Forscher und Maintainer beschreiben sie jedoch sehr unterschiedlich. Wiz spricht von Codeausf\u00fchrung nach Authentifizierung auf Root-Ebene und zeigt einen Test, der uid=0(root)<\/code>codecodecodecodecode im Gateway-Container zur\u00fcckgibt. LiteLLMs Advisory f\u00fcr dieselbe CVE bewertet sie als Niedrig (2.1 auf der CVSS-Skala) und beschreibt eine Schwachstelle, die ein Konto mit hohen Privilegien voraussetzt. Beide Beschreibungen beziehen sich auf dasselbe Verhalten: Vor Version 1.82.0-stable umgingen die Endpunkte zum Erstellen und Aktualisieren von benutzerdefinierten Code-Guardrails die Sandbox- und Musterpr\u00fcfungen des Test-Endpunkts, sodass jeder mit Zugriff Python-Code innerhalb des Containers ausf\u00fchren konnte. Das Advisory f\u00fcgt hinzu, dass eine Installation ohne Masterschl\u00fcssel Aufrufer als Proxy-Administratoren behandelte, was diese Endpunkte erreichbar machte. Nach Version 1.82.0 konnte ein Angreifer mit dem Standardschl\u00fcssel laut Wiz nur noch innerhalb einer Sandbox Code ausf\u00fchren. Ein separates Advisory von Mai, CVE-2026-40217<\/strong>, stellt fest, dass die Sandbox mit Bytecode-Techniken umgangen werden konnte, indem Code im Proxy-Prozess ausgef\u00fchrt wurde (der im Standard-Docker-Image als root l\u00e4uft). Es betrifft Versionen von 1.81.8 bis einschlie\u00dflich 1.83.9; der Zugriff auf den Endpunkt erfordert einen Proxy-Admin-Nachweis \u2013 der Masterschl\u00fcssel ist dieser Nachweis. Beide von Wiz gemeldeten Schwachstellen wurden Monate vor dem Bericht im September (Februar und April) behoben; ihre CVEs wurden im Juli ver\u00f6ffentlicht.<\/p>\n

Separate Bedrohung: Bereits ausgenutzte LiteLLM-Schwachstellen<\/h2>\n

Hierbei handelt es sich um \u00e4ltere Probleme, die nichts mit dem oben beschriebenen Weg zu Cloud-Anmeldedaten zu tun haben. Sie werden aufgef\u00fchrt, da sie dasselbe Produkt betreffen und leicht zu verwechseln sind. CISA<\/a> nahm am 2. September<\/a> eine LiteLLM-Schwachstelle in den Katalog bekannter ausgenutzter Schwachstellen auf. CVE-2026-59822<\/strong> (CVSS: 8,8), ebenfalls von Wiz entdeckt, erm\u00f6glicht einem nicht authentifizierten Angreifer die Er\u00f6ffnung einer g\u00fcltigen MCP-Sitzung mit einem beliebigen Bearer-Token, selbst einem einzelnen Zeichen. Bundesbeh\u00f6rden haben bis zum 16. September Zeit, dies zu beheben. Wiz beobachtete die Ausnutzung ab dem 7. Juli in seinen Honeypots. Diese Schwachstelle erreicht nicht die Pfade zur Codeausf\u00fchrung oder zum Diebstahl von Anmeldedaten. Eine andere Schwachstelle, CVE-2026-42271<\/strong> (CVSS: 8,7), erlaubte jedem authentifizierten Benutzer die Ausf\u00fchrung von Befehlen auf dem Host \u00fcber zwei MCP-Test-Endpunkte. Horizon3.ai berichtete im Juni, dass dies mit einer Starlette-Host-Header-Schwachstelle, CVE-2026-48710<\/strong>, kombiniert werden konnte, um dasselbe ohne Anmeldedaten zu erreichen. Wiz‘ Honeypots zeichneten auf, dass diese Schwachstelle zur Installation eines Kryptominerers genutzt wurde. Microsoft ver\u00f6ffentlichte im August einen Fall, bei dem Angreifer Befehle in einem LiteLLM-Gateway-Prozess ausf\u00fchrten, die Umgebungsvariablen des Containers nach dem Masterschl\u00fcssel, Provider-Keys und der Datenbank-Verbindungszeichenfolge durchsuchten und damit auf die PostgreSQL-Datenbank zugriffen. Microsoft bewertet mit hoher Sicherheit, dass die Angreifer \u00fcber das exponierte Gateway eindrangen, und fordert: \u201eBehandeln Sie KI-Gateways als Geheimnisse der Stufe 0.“<\/p>\n

Empfohlenes Vorgehen<\/h2>\n

Ein Upgrade auf Version 1.84.0 oder h\u00f6her behebt alle genannten Schwachstellen. Folgende Schritte sind essenziell:<\/p>\n

    \n
  1. Masterschl\u00fcssel \u00e4ndern:<\/strong> Ersetzen Sie sk-1234<\/code>codecodecodecodecode durch einen langen, zuf\u00e4lligen Wert. Dies erfordert kein Upgrade. Pr\u00fcfen Sie vorab, ob ein separater Salt-Key gesetzt ist, da das Rotationsverfahren abweicht.<\/li>\n
  2. Auf Version 1.84.0 oder h\u00f6her aktualisieren:<\/strong> Diese Version liegt \u00fcber der fixierten Version jeder Schwachstelle in der Tabelle.<\/li>\n
  3. Bei aufgeschobenem Upgrade:<\/strong> Blockieren Sie die Pfade \/mcp\/<\/code>codecodecodecodecode, POST \/mcp-rest\/test\/connection<\/code>codecodecodecodecode und POST \/mcp-rest\/test\/tools\/list<\/code>codecodecodecodecode in Ihrem Reverse Proxy.<\/li>\n
  4. Zus\u00e4tzlich blockieren:<\/strong> POST \/guardrails\/test_custom_code<\/code>codecodecodecodecode und schr\u00e4nken Sie POST \/guardrails<\/code>codecodecodecodecode und PUT \/guardrails\/{guardrail_id}<\/code>codecodecodecodecode auf Administratoren ein.<\/li>\n
  5. Durchgangs-Endpunkte pr\u00fcfen:<\/strong> Beschr\u00e4nken Sie die ausgehende Netzwerkverbindung des Containers und weisen Sie der Workload die minimal notwendige Cloud-IAM-Rolle zu.<\/li>\n
  6. Bei Verdacht auf Kompromittierung:<\/strong> \u00dcberpr\u00fcfen Sie die Guardrails-Liste, starten Sie den Prozess neu, und rotieren Sie Provider-Keys, Masterschl\u00fcssel sowie Datenbank-Anmeldedaten. Ein Upgrade entfernt weder registrierte Guardrails noch hinzugef\u00fcgte SSH-Schl\u00fcssel.<\/li>\n<\/ol>\n

    F\u00fcr den Durchgangsweg zu den Instanz-Metadaten gibt es keinen Patch, da LiteLLM dies nicht als Schwachstelle wertet. Netzbeschr\u00e4nkungen und enge IAM-Rollen sind die einzigen verf\u00fcgbaren Kontrollen. Es existiert keine Anleitung zur Pr\u00fcfung, ob MCP- oder Durchgangs-Routen auf einem \u00fcbernommenen Gateway aktiviert sind. Die Jagdqueries von Microsoft finden Ausnutzung, nicht Konfiguration.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Fast jedes zehnte LiteLLM-Gateway, das \u00fcber das Internet erreichbar ist, akzeptiert den Standard-Administrator-Schl\u00fcssel sk-1234. Diesen Wert listet die offizielle Setup-Anleitung des Open-Source-KI-Gateways als Beispiel. Unternehmen setzen LiteLLM als Vermittler zwischen ihren Anwendungen und den von ihnen bezahlten KI-Modellaaaa-Anbietern ein. Wer \u00fcber diesen Schl\u00fcssel verf\u00fcgt, kann s\u00e4mtliche API-Keys der Modellanbieter auf dem Server auslesen. In Tests […]<\/p>\n","protected":false},"author":5,"featured_media":54120,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/de\/51765.png","fifu_image_alt":"Fast jedes zehnte LiteLLM-Gateway akzeptiert Standard-Admin-Schl\u00fcssel sk-1234","footnotes":""},"categories":[6671],"tags":[],"class_list":["post-51765","post","type-post","status-publish","format-standard","has-post-thumbnail","category-scherheit"],"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/de\/51765.png","fifu_image_alt":"Fast jedes zehnte LiteLLM-Gateway akzeptiert Standard-Admin-Schl\u00fcssel sk-1234","_links":{"self":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/51765","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/comments?post=51765"}],"version-history":[{"count":2,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/51765\/revisions"}],"predecessor-version":[{"id":51768,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/51765\/revisions\/51768"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media\/54120"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media?parent=51765"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/categories?post=51765"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/tags?post=51765"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}