LONDON (IT BOLTWISE) – Eine mehrstufige Schwachstellenkette in LiteLLM erlaubt es Angreifern, von einem Standard-Account über mehrere Stufen bis zum Proxy-Admin und zur Code-Ausführung auf dem Gateway zu gelangen. Das zentrale Risiko: Wer den Proxy übernimmt, erhält nicht nur Modell- und Provider-Schlüssel, sondern auch die gespeicherten Secrets zum Entschlüsseln von Zugangsdaten. Zusätzlich können Antworten im Datenstrom manipuliert werden, was weit über klassischen Prompt-Fehlern liegt. Betroffen sind viele Setups, weil LiteLLM als OpenAI-kompatibler AI-Gateway-Connector breit genutzt wird.
LiteLLM steht in vielen Unternehmens-Setups genau an der Stelle, an der man im Alltag am wenigsten „Angriffsfläche“ erwartet: als AI Gateway, das API-Aufrufe und Authentifizierung zwischen Applikation und einer Vielzahl von Modellprovidern bündelt. Sicherheitsforscher von Obsidian Security zeigen nun, dass eine Kombination aus drei Schwachstellen aus einem Low-Privilege-Account eine vollständige Übernahme des Proxy-Servers machen kann. Der Mechanismus ist besonders gefährlich, weil das Gateway in der Regel die einzigen zentralen Hubs für Provider-Keys, gespeicherte Zugangsdaten und den gesamten Prompt-/Response-Flow darstellt. Nach Obsidian erhält die komplette Kette eine Bewertung bis CVSS 9,9 im Critical-Bereich.
Der Ausgangspunkt liegt in der Rechteprüfung rund um virtuelle API-Keys. LiteLLM nutzt ein Feld, das eigentlich die erlaubten Routen für einen Key einschränken soll. In der Praxis wird dieses „allowed_routes“-Feld bei der Generierung eines Keys durch einen nicht privilegierten Nutzer nicht gegen die Rolle des Aufrufers gegengeprüft. Dadurch kann ein Standard-Account sich einen Key konfigurieren, dessen Route-Set auch Wildcards für alle Pfade umfasst – inklusive Admin-Only-Endpunkte. Obsidian beschreibt, dass diese fehlerhafte Logik in weiteren Key-Management-Routen konsistent wiederkehrt, sodass die Korrektur in mehreren Pull Requests zusammenlief, bevor sie im Fix-Release gebündelt wurde.
Mit umgehbarer Route-Prüfung werden anschließend Handler erreichbar, die davon ausgehen, dass die Guard-Funktion bereits korrekt vorgelagert geprüft hat. Auf dieser Stufe kommt es zur Privilegeskalation: Über einen Endpunkt wie „/user/update“ kann ein Nutzer seine eigenen Daten ändern, ohne dass ein scharfes Field-Level-Filtering sicherstellt, dass Rollenattribute wie „user_role“ nur in legitimen Admin-Kontexten gesetzt werden dürfen. In der Demo reicht eine „self-update“ mit „proxy_admin“-ähnlichen Attributen, um in den vollen Admin-Status zu kippen. Parallel bewertet Obsidian zudem eine separate Komponente, die als „Custom Code Guardrail“ beschrieben wird, in der Python-Code serverseitig kompiliert und ausgeführt wird – bei der Ausführung fehlte jedoch eine harte Absicherung gegen Klassen von Escapes.
Technisch wird die Code-Execution durch Details im Python-Umfeld greifbar. In einem beschriebenen Pfad wird Code über exec() ausgeführt, ohne dass die Umgebung korrekt gegen das Einblenden von Builtins abgesperrt ist. Wenn das Globals-Objekt ein bestimmtes Muster ohne „__builtins__“ enthält, kann Python die vollständigen Builtins dennoch nachreichen; damit stehen Import-Mechanismen und elementare Funktionen wie open oder eval zur Verfügung. Obsidian zeigt, dass damit bereits ein einfacher Payload-Ansatz für eine Reverse Shell genügt. Zusätzlich berichten die Forscher von einem weiteren Weg über einen „/guardrails/test_custom_code“-Playground, der über Laufzeit-Manipulation eine Regex-Denylist aushebeln konnte. Beide Pfade enden im Ergebnis: serverseitige Codeausführung.
Damit verschiebt sich das Risiko von Datenabfluss zu operativer Kontrolle. LiteLLM sitzt als Chokepoint auf dem Draht zwischen Agent und Modell, wodurch die Reichweite weit über die reine Credential-Exfiltration hinausgeht: Angreifer können nicht nur Master- und Salt-Schlüssel gewinnen, die gespeicherte Credentials entschlüsselbar machen, sondern auch Provider-Keys für OpenAI, Anthropic, Gemini, Bedrock, Azure und weitere. Zwar sind Datenbankwerte häufig verschlüsselt, doch mit dem Salt-Schlüssel wird der Schutz faktisch wieder umkehrbar. Besonders kritisch wird die Situation, wenn das Gateway zusätzlich als Agent- oder MCP-Gateway agiert: dann kommen OAuth-Tokens und Tool-Zugriffsdaten in den Scope. Obsidian betont: „Im Ergebnis verhält sich der Zugriff auf proxy_admin wie Host-Level-Zugriff.“
Noch schärfer ist aus Angreifersicht jedoch die Möglichkeit, nicht nur zu lesen, sondern zu schreiben. Da das Gateway den gesamten Prompt- und Response-Stream kontrolliert, kann ein kompromittierter Proxy Antworten im Transit fälschen. Das ist nicht klassisches Prompt Injection, sondern eine Manipulation, die auf Callback-Mechanismen setzt: LiteLLM bietet Erweiterungspunkte, die auf jede Anfrage feuern und typischerweise nicht im Admin-UI sichtbar sind. In Obsidian-Demos kann ein Angreifer so Tool-Aufrufe und Sicherheitskontexte so umschreiben, dass nachgelagerte Aktionen als „genehmigt“ erscheinen. Der Effekt ist damit systemisch: Ein Agent, der dem Gateway vertraut, führt Anweisungen aus, die nicht mehr aus dem Modell, sondern aus dem kompromittierten Proxy stammen.
Für die Markteinschätzung lohnt sich der Blick auf ähnliche Gateways und die übliche Sicherheitsannahme. Produkte wie Kong Gateway, Envoy-gestützte API-Gateways oder spezialisierte Agent-Proxy-Lösungen verfolgen zwar unterschiedliche Architekturen, haben aber gemeinsam, dass sie Vertrauensgrenzen zwischen Komponenten verlagern. Gerade deswegen kritisiert Obsidian die Kettenlogik: Erst die Route-Prüfung vertraut dem vom Nutzer gelieferten Feld, dann vertrauen die Handler dieser vorgelagerten Entscheidung, und schließlich fehlt eine konsequente Kontrolle an mehreren Schichten. Für Security-Teams heißt das: „AI Gateway“ ist kein neutrales Routing-Frontend, sondern ein hochprivilegierter Kontrollpunkt. Obsidian ordnet die Kette als disclosed flaw mit funktionierender Demo ein – unabhängig davon, ob bereits überall in freier Wildbahn aktiv ausgenutzt wurde.
Der konkrete Handlungsweg ist relativ klar, auch wenn er operativ Aufwand bedeutet. LiteLLM sollte auf „v1.83.14-stable“ oder höher aktualisiert werden, da dort der komplette Fix-Set für die drei-CVE-Kette enthalten ist. Danach empfiehlt sich eine Audit-Runde: Wer aktuell „proxy_admin“ hält, muss wie Host-Zugriff behandelt werden, inkl. strikter Rollenvergabe, MFA und möglichst kurzer Lebensdauer von Tokens. Zusätzlich sollten Custom Code Guardrails geprüft und die Callback-Konfigurationen aus „config.yaml“ unter „litellm_settings.callbacks“ kontrolliert werden, weil genau diese Stellen im UI oft unsichtbar sind. Werden Expositionsindizien vermutet, sollten Provider-Keys, Datenbank-Credentials und gespeicherte MCP-Tokens rotiert werden. Historisch wirkt das wie ein Muster: Obsidian verweist auf frühere Ereignisse mit Supply-Chain-Manipulationen auf PyPI und auf SQL-Injection, die nach Disclosure in kurzer Zeit ausgenutzt wurde.
Aus Zukunftsperspektive ist die zentrale Frage, wie Unternehmen Gateways künftig „sandboxen“. Während Updates Lücken schließen, bleibt das systemische Designrisiko: Wenn ein Gateway Erweiterungspunkte für serverseitiges Code- oder Tool-Management bietet, muss die Ausführungsumgebung als potenziell feindlich betrachtet werden. Eine sinnvolle Entwicklungslinie wäre stärker isolierte Execution (Container-/VM-Grenzen, restriktive OS-Rechte, feste Allowed-Imports, echte Capability-basierte Modelle) und eine klare Trennung zwischen Routing, Guardrails und Ausführungs-Plugins. Entwickler profitieren davon, weil sie sicherere Integrationen aufbauen können: statt „Admin bedeutet Codeausführung“, sollte Admin maximal definierte, signierte Aktionen auslösen. Bis solche Guard-Rails standardisiert sind, bleibt: Gateways sind Hochwertziele – und deren Kompromittierung wird vermutlich weiterhin in mehrstufigen Ketten erfolgen.
💳 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.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【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-Kettenlücke: Vom Proxy-Account zum Admin und Server-RCE" 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-Kettenlücke: Vom Proxy-Account zum Admin und Server-RCE" 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-Kettenlücke: Vom Proxy-Account zum Admin und Server-RCE« bei Google Deutschland suchen, bei Bing oder Google News!