LONDON (IT BOLTWISE) – Wiz hat im Februar rund 3.074 öffentlich erreichbare LiteLLM-Gateways auf Shodan geprüft und bei knapp 10 % den Beispiel-Adminkey sk-1234 im Einsatz gefunden. Der Schlüssel wirkt zugleich als Administrationspasswort und als Schalter für Authentifizierung, sodass bei älteren Releases ohne Master Key faktisch Vollzugriff entsteht. Besonders kritisch ist dabei eine Pass-through-Funktion, die Ziel-URLs auch dann auf sensible Cloud-Endpoints lenken kann, wenn IMDSv2 aktiv ist. Obwohl LiteLLM die Code-Ausführungsprobleme in den genannten CVEs bereits geschlossen hat, zeigt die Auswertung: Die Kombination aus Default-Konfiguration und Prozessrechten bleibt ein strukturelles Risiko für KI-Gateways.
Wenige Zeilen Konfigurationsbeispiel können bei KI-Gateways plötzlich über Produktionssicherheit entscheiden. In der Untersuchung, auf die sich die aktuellen Warnungen stützen, standen öffentlich erreichbare LiteLLM-Instanzen im Fokus: Das System fungiert als Übersetzer zwischen Anwendungen und den externen Modellanbietern, die Firmen dafür bezahlen. LiteLLM bündelt dabei nicht nur Provider-Zugriffe, sondern auch Metadaten und Weiterleitungslogik. Genau an dieser Stelle wird ein Standardwert zum Risiko: Der in der eigenen Setup-Doku genutzte Beispiel-Adminkey „sk-1234“ ist zugleich ein Administrationsnachweis und ein Authentifizierungsschalter.
Die Messdaten liefern den harten Einstieg: Wiz hat im Februar 3.074 LiteLLM-Gateways auf Shodan gefunden und in 294 Fällen sk-1234 akzeptiert. In 191 dieser 294 Instanzen wurde gar kein Key gesetzt, was im Ergebnis jede Test- oder Beispielkennung akzeptieren kann. In den übrigen Fällen blieb der dokumentierte Dekompressionswert in der Konfiguration stehen, statt ihn durch einen langen Zufallsstring zu ersetzen. In einem zweiten Durchlauf im August stieg die Zahl der gefundenen Systeme auf über 85.000; Wiz weist jedoch darauf hin, dass ein großer Teil dieser zusätzlichen Treffer wie Honeypots oder Testumgebungen wirken könne. Für Unternehmen ist die Kernaussage deshalb weniger „wie viele insgesamt“, sondern „wie schnell Defaults in echte Deployments durchrutschen“.
Technisch wird das Problem durch zwei Eigenschaften verschärft. Erstens kann der Adminkey eine Vielzahl von Aktionen freischalten, die bei Gateways typischerweise nicht nur „Leserechte“, sondern auch „Betriebsrechte“ darstellen: Bei einem passenden Setup kann der Gateway-Server alle im System hinterlegten API-Schlüssel der verbundenen Provider ausgeben und zudem die Prompt- und Reply-Datenströme mitlesen, die das Gateway weiterleitet. Zweitens läuft der Gateway in vielen Setups mit den Cloud-Rechten des Workloads, in dem er deployed wurde. Für Angreifer bedeutet das: Selbst wenn nur Provider-Schlüssel gestohlen werden, lässt sich häufig damit „LLMjacking“ betreiben, also die Ausgaben für Modellinferenz dem Zielsystem zuordnen. Und sobald zusätzlich das Gateway interne Werkzeuge erreichen kann, kommt die nächste Angriffsfläche über Model Context Protocol (MCP) und konfigurierbare Tool-Server.
Der besonders brisante Pfad in der Beschreibung betrifft Pass-through-Endpoints: Ein Administrator kann in LiteLLM einen Forwarding-Route anlegen, der Anfragen an eine vom Admin gewählte Ziel-URL weiterreicht. Die Dokumentation wird dabei als problematisch dargestellt, weil offenbar keine Prüfung erfolgt, ob die Ziel-URL private Adressräume, localhost oder Cloud-Metadaten-Services betrifft. Damit entsteht ein Szenario, in dem ein Angreifer die Instanz-Metadaten (IMDS) adressieren und die zurückgelieferten IAM-Infos abgreifen kann. Wichtig ist der Detailgrad: Selbst IMDSv2 soll laut den vorliegenden Tests nicht zuverlässig als Schutz wirken, weil LiteLLM offenbar bestimmte Header übergibt, darunter auch Varianten, die für IMDSv2-Token-Mechanismen nötig sind, wenn sie mit einem x-pass- Präfix versehen werden.
Für die Einordnung der Schwachstellenlage kommen die CVEs hinzu – und damit auch die Debatte über die Schwere. Ein zentraler Punkt in der Darstellung ist CVE-2026-59821: Wiz ordnet sie als Code-Ausführung nach erfolgreichem Authentifizierung und auf Root-Ebene ein, zeigt im Test also uid=0 innerhalb des Gateway-Containers. Das LiteLLM-Worksteam bewertet die gleiche CVE dagegen als Low (2,1 auf der CVSS-Skala) und beschreibt sie als Fehler, der einen hochprivilegierten Account erfordert. Beide Erzählungen laufen jedoch auf denselben Mechanismus hinaus: In bestimmten Versionen überspringen Endpunkte für das Erstellen und Aktualisieren benutzerdefinierter Code-Guardrails Sandbox- und Pattern-Checks, sodass ein Angreifer, der diese Endpunkte erreichen kann, Python-Code im Container ausführen kann. Dass die Reichweite des Angriffs in der Konfiguration bzw. beim Default-Master-Key mitentscheiden kann, macht diese Klasse von Fehlern für Betreiber besonders unkomfortabel: Man behebt die CVE, aber die falsche Konfiguration sorgt im Grenzfall dafür, dass die Angriffsoberfläche wieder „offen“ wirkt.
Neben dieser „Default-Key-Route“ listet die Untersuchung weitere LiteLLM-Probleme, die bereits adressiert oder zumindest in der Praxis verwechselt werden können. Dazu zählt CVE-2026-59822, die als Known Exploited Vulnerability in einen Katalog der US-Behörde aufgenommen wurde; sie betrifft einen Authentication Bypass für MCP und erlaubt laut der Beschreibung eine gültige MCP-Session auch mit sehr schwachen Bearer Tokens. Ebenfalls genannt wird CVE-2026-42271, bei der authentifizierte Nutzer Befehle über zwei MCP-Testendpoints auf dem Host ausführen konnten; Wiz berichtet, dass Honeypots den Einsatz zum Installieren eines Krypto-Miners beobachtet hätten. Zusätzlich spielt eine Kettenanfälligkeit aus der Web-Schicht eine Rolle, weil laut Microsoft die Kombi aus LiteLLM-Schwäche und einem Starlette-Header-Problem ohne Credentials den Weg in die Kommandofähigkeit ebnen kann. Aus Sicht von Security-Verantwortlichen ist die Reihenfolge entscheidend: „Welche Schwachstelle öffnet Tools?“ und „Welche Konstellation erreicht dann Credentials oder Datenbanken?“ werden in Gateways sonst leicht durcheinandergeworfen.
Für die Praxis ergeben sich konkrete Prioritäten, weil LiteLLM laut der Zusammenstellung „alle Flaws in der Tabelle“ durch ein Upgrade auf Version 1.84.0 oder höher abdeckt. Gleichzeitig bleibt der wichtigste Sofortschritt unabhängig vom Patch-Stand: der Wechsel von sk-1234 auf einen langen Zufallswert, ohne dabei die Rotation eines möglichen separaten Salt Key zu verwechseln. Wenn ein Upgrade kurzfristig nicht möglich ist, rücken Netzwerk- und Exfiltrationskontrollen in den Vordergrund: Die Empfehlungen richten sich auf das Blocken der MCP-Pfade und der MCP-Testendpoints, etwa POST /mcp-rest/test/connection und POST /mcp-rest/test/tools/list, sowie das Einschränken der Guardrails-Testfunktionen und das Rollenmodell für POST /guardrails und PUT /guardrails/{guardrail_id}. Daneben wird zu einer kritischen Architekturentscheidung gedrängt: Pass-through-Routen sollten überprüft, Outbound-Netzwerkzugriffe stark begrenzt und das Cloud-IAM-Profil des Workloads möglichst auf die minimal nötigen Rechte reduziert werden.
Unverändert bleibt auch ein organisatorischer Punkt: Wenn ein Angreifer überhaupt über Default-Credentials oder einen erreichbaren Authentifizierungsfehler Zugriff hatte, reicht ein „nur Software aktualisieren“ nicht aus. Die Beschreibung empfiehlt dann, Guardrails-Einträge zu prüfen, die nicht selbst erstellt wurden, und den Prozess neu zu starten, um potenziell im Speicher gehaltenen Code zu entfernen. Anschließend sollten Provider-Keys, Master Key und Datenbankzugangsdaten rotiert werden – denn ein erfolgreiches Update löscht nicht automatisch Fremdeinträge, etwa zusätzliche SSH-Keys, die ein Angreifer bereits hinterlegt haben könnte. Für Betreiber heißt das am Ende: KI-Gateways müssen wie Tier-0 Secrets Stores behandelt werden, weil sie durch ihre Architektur sowohl Authentifizierung als auch Datenfluss und Werkzeugintegration bündeln.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "LiteLLM: Default-Admin-Key sk-1234 öffnete Server- und Cloud-Zugriff" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "LiteLLM: Default-Admin-Key sk-1234 öffnete Server- und Cloud-Zugriff" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »LiteLLM: Default-Admin-Key sk-1234 öffnete Server- und Cloud-Zugriff« bei Google Deutschland suchen, bei Bing oder Google News!