LiteLLM CVE-2026-47101, -47102, -40217: Vom internen Nutzer zu proxy_admin und RCE — eine Drei-Lücken-Kette im AI-Gateway

TL;DR — 90 Sekunden

Betroffen?

Alle LiteLLM-Proxy-Deployments vor Version v1.83.14-stable mit mehreren Nutzerrollen (insbesondere internal_user-Accounts) und/oder aktivierten Custom Code Guardrails.

Risiko?

Drei einzeln bereits ernste Lücken (CVSS 4.0 je ~8.7) lassen sich verketten: CVE-2026-47101 erlaubt einem internal_user, sich per allowed_routes Zugriff auf Admin-Routen freizuschalten; CVE-2026-47102 erlaubt die Selbst-Eskalation zu proxy_admin über /user/update; CVE-2026-40217 erlaubt über eine Sandbox-Lücke im Custom Code Guardrail beliebige Python-Code-Ausführung. Kombiniert: von einem gewöhnlichen internen Account zu vollständiger RCE auf dem Proxy-Server.

Sofortmaßnahme?

Auf litellm >= 1.83.14-stable aktualisieren. Alle proxy_admin-Zuweisungen auditieren, Custom Code Guardrails in der config.yaml auf unautorisierte Änderungen prüfen (im UI teils nicht sichtbar).

Empfehlung?

Wer LiteLLM als zentrales AI-Gateway mit mehreren Nutzerrollen betreibt, patcht zeitnah und rotiert vorsorglich Provider-API-Keys und DB-Credentials. Keine bestätigte Exploitation in freier Wildbahn bekannt, aber ein öffentlich dokumentierter Proof-of-Concept existiert.

Kritikalität?

high — kein unauthentifizierter Pre-Auth-RCE, aber die Kette startet bei jedem gewöhnlichen internen Account und endet bei vollständiger Serverkompromittierung.

Was ist das Problem?

LiteLLM ist ein quelloffenes AI-Gateway/Proxy, der einheitlichen Zugriff auf über 100 verschiedene LLM-Provider (OpenAI, Anthropic, Azure, Bedrock u.v.m.) bündelt und typischerweise zentral im Unternehmen betrieben wird — mit Zugriff auf sämtliche Provider-API-Keys, oft auch auf interne Datenbanken für Budget-Tracking, Nutzerverwaltung und Logging. Drei unabhängig entdeckte, aber kombinierbare Schwachstellen erlauben es einem Nutzer mit der niedrigsten Standard-Rolle (internal_user), sich schrittweise zum vollen Administrator hochzuarbeiten und am Ende beliebigen Code auf dem Proxy-Server auszuführen:

CVE-2026-47101 — Autorisierungs-Bypass bei der Schlüsselerstellung

Endpunkte wie /key/generate akzeptieren ein allowed_routes-Feld, mit dem festgelegt wird, auf welche API-Routen ein neu erstellter Schlüssel zugreifen darf. LiteLLM validiert dabei nicht, ob die angeforderten Routen zur Rolle des anfragenden Nutzers passen (CWE-863, Incorrect Authorization) — ein internal_user kann sich selbst einen Schlüssel mit Zugriff auf eigentlich admin-exklusive Routen ausstellen.

CVE-2026-47102 — Selbst-Eskalation zu proxy_admin

Die Endpunkte /user/update und /user/bulk_update prüfen nicht auf Feld-Ebene, welche Attribute ein Nutzer an seinem eigenen Konto ändern darf. Mit dem über CVE-2026-47101 erlangten Zugriff kann ein Nutzer das eigene user_role-Feld direkt auf proxy_admin setzen und erhält damit volle administrative Rechte auf der Instanz.

CVE-2026-40217 — Sandbox-Escape im Custom Code Guardrail

LiteLLM erlaubt Administratoren, sogenannte „Custom Code Guardrails“ zu konfigurieren — benutzerdefinierten Python-Code, der Prompts/Responses vor der Verarbeitung prüft oder transformiert. Dieser Code wird per exec() ausgeführt, ohne __builtins__ aus dem Ausführungskontext zu entfernen: __import__, open und eval bleiben erreichbar, was faktisch beliebige Codeausführung erlaubt. Zusätzlich lässt sich ein Regex-basierter Deny-List-Filter am Playground-Endpoint durch Bytecode-Manipulation umgehen. Mit den über CVE-2026-47101/-47102 erlangten proxy_admin-Rechten kann ein Angreifer einen bösartigen Guardrail konfigurieren und ausführen lassen.

Wer ist betroffen?

Alle drei CVEs betreffen den LiteLLM-Proxy-Server selbst (nicht die SDK-Bibliothek für Client-Integrationen). Da die genaue untere Versionsgrenze in den verfügbaren Quellen nicht einheitlich beziffert wird, gilt praktisch: jede produktive Instanz unterhalb von v1.83.14-stable sollte als betroffen behandelt werden.

Auswirkungen

Der Proxy-Server ist in typischen Deployments ein hochprivilegierter zentraler Knotenpunkt: Er hält Provider-API-Keys für alle angebundenen LLM-Dienste, Datenbank-Credentials für die eigene Nutzer-/Budget-Verwaltung, verschlüsselt gespeicherte Secrets (die bei Kenntnis des Salt-Keys wiederherstellbar sind) sowie sämtliche durchgeleiteten Prompts und Responses — potenziell inklusive personenbezogener Daten und internem Quellcode, der zur Analyse an ein LLM geschickt wurde.

Ein Angreifer, der die volle Kette durchläuft, erhält Code-Ausführung mit den Rechten des Proxy-Prozesses. Das bedeutet: vollständigen Zugriff auf alle genannten Secrets, die Möglichkeit, den Datenverkehr zu allen angebundenen LLM-Providern mitzulesen oder umzuleiten, und je nach Netzwerksegmentierung einen Sprungpunkt in interne Systeme. Die Kette erfordert als Startpunkt einen authentifizierten Account unterhalb von proxy_admin — ein Pre-Auth-Angriff ohne jegliche Zugangsdaten ist damit nicht der Weg, wohl aber jeder interne oder versehentlich zu weit vergebene Zugang.

Mitigation / Sofortmaßnahmen

Operativer Entscheidungsblock

• Jetzt handeln, wenn … Ihre LiteLLM-Instanz mehrere Nutzerrollen aktiv nutzt (nicht nur ein einzelner proxy_admin-Account) und/oder Custom Code Guardrails konfiguriert sind.
• Mit Priorität prüfen, wenn … LiteLLM als zentrales, unternehmensweites AI-Gateway mit Zugriff auf mehrere Provider-API-Keys betrieben wird.
• Im nächsten regulären Fenster, wenn … es sich um eine Single-User-Testinstanz ohne produktive Secrets handelt.

Schritt 1 — auf v1.83.14-stable oder neuer aktualisieren

# aktuelle Version prüfen
pip show litellm | grep Version
# bzw. im Docker-Deployment:
docker exec <litellm-container> pip show litellm

# aktualisieren (pip-Installation)
pip install "litellm>=1.83.14"

# aktualisieren (Docker)
docker pull ghcr.io/berriai/litellm:main-v1.83.14-stable
# docker-compose.yml / Helm-Chart entsprechend auf den neuen Tag anpassen und neu ausrollen

Schritt 2 — proxy_admin-Zuweisungen auditieren

# alle Nutzer mit ihrer aktuellen Rolle auflisten (Proxy-Admin-API, Beispiel)
curl -s -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  <litellm-host>/user/list | jq '.users[] | {user_id, user_role}'

# gezielt nach unerwarteten proxy_admin-Zuweisungen filtern
curl -s -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  <litellm-host>/user/list | jq '.users[] | select(.user_role=="proxy_admin")'

Jede proxy_admin-Zuweisung, die nicht eindeutig einem bekannten, autorisierten Administrator zugeordnet werden kann, sollte umgehend zurückgesetzt werden.

Schritt 3 — Custom Code Guardrails prüfen und ggf. deaktivieren

# config.yaml nach Guardrail-Definitionen durchsuchen — im UI teils nicht vollständig sichtbar
grep -A 10 "guardrails:" config.yaml

# bis zum Patch: Custom-Code-Guardrails deaktivieren oder auf bekannten,
# geprüften Code beschränken, statt Nutzer-Input in der Konfiguration zuzulassen

Schritt 4 — bei Verdacht auf Kompromittierung: Secrets rotieren

Provider-API-Keys (OpenAI, Anthropic, Azure, Bedrock etc.), die Datenbank-Zugangsdaten der LiteLLM-Instanz sowie den Master-/Salt-Key rotieren, sobald ein Verdacht auf unautorisierte proxy_admin-Zugriffe besteht.

Detection / Prüfung

Version prüfen

pip show litellm | grep Version
# oder im laufenden Container:
docker exec <litellm-container> python -c "import litellm; print(litellm.__version__)"

Auf verdächtige Rollenänderungen prüfen

# Audit-/Zugriffslogs nach Aufrufen von /user/update und /user/bulk_update durchsuchen,
# bei denen sich user_role auf proxy_admin geändert hat
grep -E "/user/(bulk_)?update" litellm.log | grep -i "proxy_admin"

# API-Key-Erstellungen mit auffälligem allowed_routes-Feld auffinden
grep "/key/generate" litellm.log | grep -i "allowed_routes"

Guardrail-Konfiguration auf unbekannten Code prüfen

# alle in config.yaml referenzierten Custom-Code-Guardrails auflisten und Diff gegen
# die letzte bekannte, geprüfte Version ziehen
git diff HEAD~10 -- config.yaml | grep -A 20 "guardrails:"

Da keine öffentlich bestätigte Ausnutzung in freier Wildbahn dokumentiert ist, gibt es keine etablierten IOCs Dritter — die genannten Prüfungen dienen der eigenen Verifikation, ob die Lücken in der eigenen Instanz bereits ausgenutzt wurden, nicht dem Abgleich mit bekannten Angriffsmustern.

Betreiberempfehlung

Mid-Market

Zeitnah auf v1.83.14-stable oder neuer aktualisieren, insbesondere wenn LiteLLM mehreren Teams mit unterschiedlichen Rollen zur Verfügung steht. Ein Notfall-Rollout am Wochenende ist bei fehlender bestätigter Exploitation nicht zwingend, ein Patchfenster innerhalb weniger Tage aber angemessen angesichts der Kombination aus Schweregrad und Zentralität des Proxy-Servers.

Enterprise / Multi-Tenant

Vollständiges Audit aller proxy_admin-Zuweisungen und aktiven Custom Code Guardrails vor dem Update, da die Lücken bereits vor dem Patch ausgenutzt worden sein könnten. Nach dem Update: Rotation aller Provider-API-Keys und Datenbank-Credentials als Vorsichtsmaßnahme, wenn interne Nutzerrollen breiter vergeben sind als für den Betrieb nötig.

Wer LiteLLM nur mit einem einzelnen Admin-Account betreibt

Das direkte Eskalationsrisiko ist geringer, da kein separater internal_user-Account als Einstiegspunkt existiert. Ein Update bleibt trotzdem empfohlen, da zukünftige Team-Erweiterungen oder Integrationen (etwa CI/CD-Systeme mit eigenen API-Keys) neue interne Accounts unterhalb von proxy_admin schaffen können.

Entscheidungsblock

Heute handeln, wenn: mehrere Nutzerrollen aktiv sind und/oder Custom Code Guardrails konfiguriert sind. Innerhalb weniger Tage, wenn: LiteLLM produktiv, aber mit nur einem Admin-Account betrieben wird. Reguläres Wartungsfenster, wenn: es sich um eine isolierte Testinstanz ohne produktive Secrets handelt.

Fazit

Diese Drei-Lücken-Kette ist ein Lehrbuchbeispiel dafür, warum Autorisierungsprüfungen nicht nur pro Endpunkt, sondern konsequent auf Feld- und Rollen-Ebene durchgesetzt werden müssen: Jede einzelne der drei Lücken ist für sich genommen bereits ernst, aber ihre Kombination — von einem gewöhnlichen internen Account bis zur vollständigen Serverkompromittierung — zeigt, wie schnell isoliert wirkende Bugs zu einer vollständigen Kompromittierungskette werden. Für ein zentrales AI-Gateway wie LiteLLM, das typischerweise Zugriff auf sämtliche Provider-Secrets eines Unternehmens bündelt, ist die Konsequenz eindeutig: striktes Least-Privilege bei internen Rollen, Vorsicht bei nutzerdefiniertem Code in Guardrails, und ein Patch-Rhythmus, der nicht erst bei aktiver Ausnutzung greift.

Quellen

• GitHub Advisory Database — GHSA-qrc4-49gv-mv9m (CVE-2026-47101)
• Obsidian Security — Breaking LiteLLM: From Low-Privilege User to Admin and RCE
• The Hacker News — LiteLLM Vulnerability Chain Lets Low-Privilege Users Take Over AI Gateway Servers
• GitHub — BerriAI/litellm Security Advisories