LiteLLM: Ein Schlüssel für Geheimnisse und Sitzungen macht interne Nutzer zum Proxy-Admin

Am 30. September 2026 hat BerriAI für den LiteLLM-Proxy das Advisory GHSA-7hp6-4w63-5g45 veröffentlicht, Schweregrad kritisch, CVSS 9,9. Der Proxy verwendet denselben Schlüssel, den Salt Key, für zwei Aufgaben: Er verschlüsselt damit gespeicherte Geheimnisse und stellt damit Sitzungstoken aus. Ein angemeldeter Nutzer mit der Rolle internal_user kann sich so zum proxy_admin machen und anschließend über den MCP-stdio-Endpunkt beliebige Befehle auf dem Host ausführen. Ab Version 1.91.0 ist das in der Standardkonfiguration möglich. Am 1. Oktober folgte GHSA-g5ff-637f-6q2m mit CVSS 8,1, ein Lesezugriff auf lokale Dateien, über den sich der Master Key auslesen lässt.

Wie die Rechteausweitung abläuft

Laut Advisory fordert der Angreifer einen neuen API-Key an und legt dabei in ein Metadatenfeld eine gefälschte Admin-Kennung als „Geheimnis" ab. LiteLLM verschlüsselt diesen Wert mit dem Salt Key und gibt das Ergebnis zurück. Schickt der Angreifer das Chiffrat danach als Bearer-Token, entschlüsselt der Proxy es mit demselben Schlüssel, liest die Admin-Kennung heraus und behandelt die Anfrage als Proxy-Admin. Mit Admin-Rechten steht der MCP-stdio-Endpunkt offen, und darüber startet der Proxy Prozesse auf seinem eigenen Host.

Der Fehler steckt im Entwurf. Ein Schlüssel, der Daten für Nutzer verschlüsselt, darf nie auch Identitäten bestätigen, weil jeder Nutzer, der sich etwas verschlüsseln lassen kann, damit ein gültiges Token in der Hand hält. Gemeldet wurde die Lücke von Hoa Nguyen aus dem Team OPSWAT Unit 515.

Betroffene Versionen und Fixes

Alle Angaben stammen aus den drei Advisories, abgerufen über die GitHub-API am 3. Oktober 2026. Die Fix-Versionen sind am 30. September als Releases erschienen.

Die Fixes für die kritische Lücke sind auf mehrere Release-Linien verteilt. Innerhalb jeder Linie gilt: 1.101.0 bis 1.101.2 sind betroffen, 1.101.3 nicht, entsprechend bei 1.102 und 1.103. Wer eine Version zwischen 1.91.0 und 1.100.3 betreibt, ist in der Standardkonfiguration angreifbar. Eine CVE-Nummer ist auf keiner der gelesenen Seiten vergeben, und keine Quelle berichtet von Angriffen.

Der zweite Weg zum Admin: /proc/self/environ

GHSA-g5ff-637f-6q2m braucht noch weniger Rechte. Der Endpunkt /utils/transform_request hatte eine Sperrliste für gefährliche Felder im Anfragekörper. Sie blockierte vertex_credentials, aber nicht den gleichbedeutenden Namen vertex_ai_credentials. Über dieses Feld gelangt ein Dateipfad in den Credential-Loader für Vertex AI, der die Datei liest und den Inhalt an eine URL des Angreifers schickt. Dafür genügt nach Angabe von BerriAI die Rolle internal_user_viewer, die viele Installationen jedem gewähren, der sich per SSO anmeldet.

Liest der Angreifer /proc/self/environ, erhält er die Umgebungsvariablen des Proxy-Prozesses und damit LITELLM_MASTER_KEY sowie die API-Keys der angebundenen Anbieter. Mit dem Master Key ist er Proxy-Admin. Einen Konfigurationsschalter gegen diesen Weg gibt es laut BerriAI nicht, behoben ist er ab 1.95.0.

Die dritte Meldung, GHSA-hhww-mrg2-969h, betrifft /sso/debug/callback. Der Endpunkt hat Felder vom Identitätsanbieter ungefiltert in einen Script-Block geschrieben. Ein präparierter Anzeigename führt Skript im Ursprung des Proxys aus, sobald ein angemeldeter Admin den Link öffnet. Betroffen sind 1.65.5 bis vor 1.85.0.

Die Falle beim Update

Wer heute auf einer Version vor 1.91.0 läuft und den experimentellen UI-Login nicht gesetzt hat, ist von der kritischen Lücke nicht betroffen, vom Dateizugriff aber schon. Ein Update auf 1.95.0 schließt den Dateizugriff und öffnet die Admin-Übernahme in der Standardkonfiguration, weil 1.95.0 in der Spanne ab 1.91.0 liegt. Das Ziel beim Update muss deshalb eine der fünf Fix-Versionen der kritischen Lücke sein, alle liegen über 1.95.0 und enthalten damit beide Korrekturen.

Als Übergang nennt das Advisory EXPERIMENTAL_UI_LOGIN=false. Der Schalter legt den betroffenen Anmeldepfad still, kostet aber CLI-SSO und die Gateway-Anmeldung von Claude Code. Gegen den Dateizugriff hilft er nicht.

Stand bei uns

Unsere beiden LiteLLM-Gateways liefen am 3. Oktober auf 1.89.4, EXPERIMENTAL_UI_LOGIN ist nicht gesetzt, und der API-Port ist nur an localhost gebunden. Die kritische Lücke trifft diesen Stand nicht, weil 1.87.0 bis 1.90.x nur mit gesetztem Schalter angreifbar sind. Die XSS-Lücke betrifft nur Versionen vor 1.85.0. Der Dateizugriff aus GHSA-g5ff-637f-6q2m gilt dagegen für 1.89.4, ausnutzbar für jeden, der einen Key mit internal_user_viewer besitzt. Am Abend des 3. Oktober haben wir beide auf 1.100.4 gehoben, eine der vier Linien mit dem Fix für die kritische Meldung, die den Dateizugriff aus 1.95.0 ebenfalls enthält. Weitere Härtungspunkte für das Gateway stehen im Security-Audit des LiteLLM-Gateways, den Aufbau der Strecke beschreibt Eigene KI-Strecke mit LiteLLM und vLLM.

Wer LiteLLM betreibt, sollte zuerst die laufende Version auslesen und gegen die Tabelle halten, dann prüfen, wer Keys mit internal_user oder internal_user_viewer hat und ob SSO solche Rollen automatisch vergibt. Danach direkt auf 1.100.4 oder eine der anderen Fix-Versionen gehen und den Master Key tauschen, wenn vorher jemand mit Viewer-Rechten Zugang hatte, dem man nicht vollständig traut.

Weiterführende Quellen

• GHSA-7hp6-4w63-5g45, kritisch: Admin-Übernahme über den mehrfach genutzten Salt Key
• GHSA-g5ff-637f-6q2m, hoch: Lesen lokaler Dateien über vertex_ai_credentials
• GHSA-hhww-mrg2-969h, mittel: reflektiertes XSS in /sso/debug/callback
• LiteLLM-Release v1.100.4, eine der Fix-Versionen vom 30.9.2026
• Security-Audit unseres LiteLLM-Gateways
• Eigene KI-Strecke mit LiteLLM und vLLM