LiteLLM-Sicherheitslücke GHSA-7hp6-4w63-5g45: Versionen prüfen und Gateway absichern

LiteLLM im Unternehmen betreiben? WZ-IT prüft, aktualisiert und härtet LiteLLM-Gateways und übernimmt den Betrieb mit CVE-Monitoring, siehe Managed LiteLLM und CVE-Monitoring. Termin vereinbaren

Am 30. September 2026 hat BerriAI ein Sicherheitsadvisory für den LiteLLM-Proxy veröffentlicht: GHSA-7hp6-4w63-5g45. Ein angemeldeter Nutzer mit der Rolle internal_user kann sich damit zum proxy_admin machen und anschließend über den MCP-stdio-Endpunkt beliebige Befehle auf dem Host ausführen. GitHub bewertet die Lücke mit CVSS 9.9.

LiteLLM ist in vielen Unternehmen die zentrale Zugriffsschicht für Sprachmodelle: Es bündelt lokale Modelle und Anbieter-APIs hinter einem OpenAI-kompatiblen Endpunkt, verwaltet Schlüssel und Budgets und hält dafür die Zugangsdaten aller angebundenen Anbieter. Wer dieses Gateway übernimmt, hat Zugriff auf genau diese Zugangsdaten. Was LiteLLM leistet und wie es im Stack sitzt, erklärt der Artikel Was ist LiteLLM?.

Dieser Beitrag fasst zusammen, wie die Lücke funktioniert, welche Versionen betroffen und gepatcht sind, was der Workaround kostet und mit welcher Checkliste sich ein LiteLLM-Gateway über diesen Fall hinaus absichern lässt. Alle Versionsangaben haben den Stand 1. Oktober 2026.

Inhaltsverzeichnis

1. Die Lücke in Kürze
2. Wie die Rechteausweitung funktioniert
3. Betroffene und gepatchte Versionen
4. Workaround, wenn das Update warten muss
5. Was nach einem möglichen Missbrauch zu prüfen ist
6. LiteLLM-Schwachstellen 2026 im Überblick
7. Checkliste: LiteLLM-Gateway absichern
8. Unser Vorgehen bei WZ-IT
9. Weiterführende Guides

Die Lücke in Kürze

Quelle: GitHub Security Advisory GHSA-7hp6-4w63-5g45.

Der Vektor beschreibt eine Lücke, die über das Netz ohne Nutzerinteraktion ausnutzbar ist und nur niedrige Rechte voraussetzt. S:C (Scope Changed) bedeutet, dass die Auswirkung über die angegriffene Komponente hinausgeht: Aus einem Nutzerkonto im Gateway wird Codeausführung auf dem Server.

Wie die Rechteausweitung funktioniert

Der Kern des Problems ist ein Schlüssel mit zwei Aufgaben. LiteLLM verwendet laut Advisory denselben Schlüssel, um gespeicherte Geheimnisse zu verschlüsseln, und um Sitzungstoken auszustellen. In der Dokumentation heißt dieser Schlüssel LITELLM_SALT_KEY; er verschlüsselt unter anderem die in der Datenbank hinterlegten Zugangsdaten der Modellanbieter (LiteLLM, Production Best Practices).

Der Ablauf nach Advisory:

1. Der Angreifer meldet sich mit einem Konto der Rolle internal_user an.
2. Er fordert einen neuen API-Schlüssel an und legt in einem Metadatenfeld einen gefälschten Admin-Nachweis als vermeintliches Geheimnis ab.
3. Der Proxy verschlüsselt diesen Wert mit dem gemeinsamen Schlüssel und gibt das Ergebnis zurück.
4. Der Angreifer verwendet den verschlüsselten Wert als Bearer-Token.
5. Der Proxy entschlüsselt das Token, hält die gefälschte Admin-Identität für gültig und gewährt volle Administratorrechte.
6. Als proxy_admin kann der Angreifer über den MCP-stdio-Endpunkt Befehle auf dem Host ausführen.

Das Muster ist ein klassischer Confused-Deputy-Fall (CWE-441): Der Proxy wird zum Werkzeug, das dem Angreifer ein gültiges Token erzeugt. Kryptografisch ist an der Verschlüsselung nichts gebrochen. Die Schwäche liegt darin, dass Daten aus zwei Vertrauensbereichen mit demselben Schlüssel geschützt werden und der Proxy nicht unterscheidet, wofür ein entschlüsselter Wert gedacht war.

Die Rolle proxy_admin ist in LiteLLM die höchste Rolle mit voller Kontrolle über Organisationen, Teams und Nutzer. internal_user darf sich anmelden, eigene Schlüssel einsehen und je nach Team-Berechtigung eigene Schlüssel anlegen (LiteLLM, Access Control). Der Abstand zwischen diesen beiden Rollen ist das, was die Lücke überbrückt.

Der MCP-stdio-Transport startet einen lokalen Prozess mit command und args aus der Konfiguration (LiteLLM, MCP). Das ist für MCP-Server gewollt, macht aber jede Möglichkeit, stdio-Server anzulegen oder zu testen, zu einer Befehlsausführung auf dem Gateway-Host. Warum MCP-Server grundsätzlich wie Code mit eigenen Rechten behandelt werden sollten, beschreibt der Artikel zum Model Context Protocol im Unternehmen.

Betroffene und gepatchte Versionen

Das Advisory unterscheidet zwei Fälle: Ab Version 1.91.0 ist der angreifbare Pfad in der Standardkonfiguration aktiv. In den Versionen 1.87.0 bis 1.90.x ist er nur aktiv, wenn EXPERIMENTAL_UI_LOGIN=true ausdrücklich gesetzt wurde.

Quellen: Versionsbereiche aus dem Advisory, Release-Daten aus den LiteLLM-Releases. Am 1. Oktober 2026 folgten mit 1.101.4 und 1.103.2 weitere Releases in diesen Linien.

Drei Punkte, die in der Praxis leicht übersehen werden:

• Keine Backports für 1.91 bis 1.99. Wer eine Version aus diesen Linien betreibt, findet dort keinen Fix. Der betroffene Bereich reicht bis unter 1.100.4. Das gilt auch für Linien, die im August 2026 noch Sicherheitsupdates für andere Lücken bekommen haben.
• Docker-Images folgen derselben Nummerierung. Die offiziellen Images liegen unter ghcr.io/berriai/litellm mit Tags wie v1.100.4. Ein Tag wie main-latest sagt wenig darüber aus, welche Version tatsächlich läuft.
• Versionsprüfung. Die laufende Version zeigt pip show litellm in der Python-Umgebung oder das Feld litellm_version in der Antwort von /health/readiness. Bei Containern ist der tatsächlich gestartete Image-Tag maßgeblich, nicht der in einer Compose-Datei vorgesehene.

Für ältere Versionen vor 1.87.0 gilt diese Lücke nicht. Diese Versionen sind aber von anderen, teils aktiv ausgenutzten Lücken betroffen (siehe Überblick 2026) und kein sicherer Zustand.

Am selben Tag erschien ein zweites Advisory: GHSA-hhww-mrg2-969h, ein reflektiertes Cross-Site-Scripting in /sso/debug/callback (CVSS 6.8) in den Versionen 1.65.5 bis unter 1.85.0. Wer auf eine der gepatchten Versionen oben aktualisiert, ist auch davon nicht mehr betroffen.

Workaround, wenn das Update warten muss

Das Advisory nennt einen Workaround: die Umgebungsvariable EXPERIMENTAL_UI_LOGIN=false setzen. Damit wird der angreifbare Anmeldepfad abgeschaltet. In der Token-Prüfung von LiteLLM wird dieser Pfad nur übersprungen, wenn die Variable ausdrücklich auf false steht (litellm/proxy/auth/user_api_key_auth.py). Ein fehlender Eintrag reicht also nicht.

Wer Entwicklerwerkzeuge über das Gateway anbindet, sollte den Workaround daher als kurze Brücke planen: setzen, Proxy neu starten, Nutzer informieren, Update testen und einspielen, Variable danach bewusst neu bewerten.

Was nach einem möglichen Missbrauch zu prüfen ist

Das Update schließt die Lücke, macht aber eine bereits erfolgte Ausnutzung nicht rückgängig. Ob sie stattgefunden hat, lässt sich nicht pauschal beantworten. Die Prüfung richtet sich danach, wer Zugriff auf Konten mit der Rolle internal_user hatte und wie lange eine betroffene Version lief.

Ist ein Missbrauch nicht auszuschließen, gehören zur Bereinigung:

• Provider-Schlüssel rotieren. Ein proxy_admin kann die hinterlegten Modellzugänge nutzen, und über Befehlsausführung auf dem Host ist auch der Zugriff auf Umgebungsvariablen möglich.
• Master Key rotieren. Der LITELLM_MASTER_KEY ist die Admin-Anmeldung für API und Oberfläche; LiteLLM dokumentiert dafür einen eigenen Rotationsablauf (Production Best Practices).
• Salt Key nur geplant ändern. Die Dokumentation warnt, dass ein geänderter LITELLM_SALT_KEY die bereits verschlüsselten Zugangsdaten unlesbar macht. Ein Wechsel heißt also, alle Modellzugänge neu zu hinterlegen.
• Host neu aufsetzen. Bei Hinweisen auf Befehlsausführung ist ein sauber neu aufgesetzter Container oder Host verlässlicher als die Suche nach jeder einzelnen Veränderung.

Ob ein Vorfall nach DSGVO oder NIS2 meldepflichtig ist, hängt davon ab, welche Daten über das Gateway liefen und welche Systeme vom Host aus erreichbar waren.

LiteLLM-Schwachstellen 2026 im Überblick

GHSA-7hp6-4w63-5g45 ist nicht die erste kritische LiteLLM-Lücke in diesem Jahr. Drei frühere Lücken stehen im Katalog Known Exploited Vulnerabilities der US-Behörde CISA, also mit belegter Ausnutzung.

Stand 1. Oktober 2026; die vollständige Liste aller Advisories führt BerriAI unter Security Advisories. Hinzu kommt der Lieferkettenvorfall vom 24. März 2026: Die PyPI-Pakete litellm 1.82.7 und 1.82.8 waren rund 40 Minuten lang kompromittiert, ausgelöst über eine kompromittierte Trivy-Abhängigkeit in der CI-Pipeline. Das offizielle Docker-Image war laut BerriAI nicht betroffen (LiteLLM, Security Update März 2026).

Daraus ergeben sich zwei Folgerungen für den Betrieb:

• MCP ist die wiederkehrende Angriffsfläche. Zwei der drei ausgenutzten Lücken und die aktuelle Lücke führen über MCP. Wer MCP im Gateway nicht braucht, verringert mit dem Abschalten die Angriffsfläche deutlich.
• Die Taktung ist hoch. LiteLLM veröffentlicht mehrere Releases pro Woche und pflegt mehrere stabile Linien parallel. Ohne festen Update-Prozess fällt ein Gateway innerhalb weniger Wochen aus dem gepatchten Bereich. Wie strukturiertes Schwachstellen-Monitoring für selbst betriebene Software aufgebaut wird, beschreibt der Beitrag CVE-Monitoring für Self-Hosted Software.

Ein ähnliches Muster zeigte im Frühjahr die Ollama-Lücke Bleeding Llama: Selbst betriebene KI-Komponenten sind nur so sicher wie ihr Betrieb. Für n8n, das häufig mit LiteLLM kombiniert wird, fasst der Beitrag zum n8n-Sicherheitsupdate September 2026 die aktuellen Advisories zusammen.

Checkliste: LiteLLM-Gateway absichern

Die folgende Checkliste geht über die aktuelle Lücke hinaus. Sie richtet sich an Betreiber, die LiteLLM als zentrales Gateway für mehrere Teams oder Anwendungen einsetzen.

Zum Netzsegment: Die verbreitete Annahme, ein Gateway im internen Netz sei geschützt, greift bei dieser Lücke nicht. Der Angreifer braucht ein gültiges Nutzerkonto, also kommt er in der Regel aus dem internen Netz oder über ein übernommenes Konto. Netzsegmentierung reduziert die Angriffsfläche, ersetzt aber weder das Update noch eine knappe Rollenvergabe.

Zu MCP: Ein MCP-Server mit stdio-Transport ist ein Prozess auf dem Gateway-Host. Wer MCP-Werkzeuge für Agenten bereitstellt, sollte diese eher als eigene Dienste mit HTTP-Transport in einem getrennten Segment betreiben und im Gateway nur freigeben, statt beliebige Befehle auf dem Gateway selbst zu starten. Wie Agenten mit begrenzten Rechten und Freigabeschritten arbeiten, beschreibt der Artikel KI-Agenten: Rechte und Freigaben.

Zur Anbieterwahl: Das Gateway ist auch der Ort, an dem festgelegt wird, welche Modelle überhaupt erreichbar sind. Wie europäische Modell-APIs und eigene Inferenz über LiteLLM kombiniert werden, zeigt der Vergleich europäischer LLM-APIs.

Unser Vorgehen bei WZ-IT

WZ-IT betreibt LiteLLM als Managed LiteLLM mit TLS, Netzsegmentierung, Monitoring und festen Betriebsprozessen. Bei einem Advisory wie GHSA-7hp6-4w63-5g45 läuft die Arbeit in fünf Schritten:

1. Betroffenheit feststellen. Laufende Version, Image-Tag, gesetzte Umgebungsvariablen und aktive Anmeldewege erfassen und gegen die Versionsbereiche des Advisorys abgleichen.
2. Absichern bis zum Update. Bei Bedarf EXPERIMENTAL_UI_LOGIN=false setzen und die Auswirkungen auf CLI-Logins mit den Nutzern abstimmen.
3. Update einspielen. Gepatchte Version in einer Testumgebung prüfen, Routing, Fallbacks, Budgets und Integrationen testen, danach im Betrieb ausrollen.
4. Spuren prüfen. Rollen, Schlüssel, MCP-Einträge und Logs auf Auffälligkeiten durchsehen; bei Verdacht Schlüssel kontrolliert rotieren.
5. Härten und dauerhaft überwachen. Checkliste oben umsetzen und das Gateway in das CVE-Monitoring aufnehmen, das neben der NVD auch die Security-Advisories der Hersteller auswertet.

Das Gateway kann neben eigener Inferenz auf dem AI Cube oder einem Managed GPU-Server von WZ-IT auch europäische Modell-APIs anbinden. Support, Beratung und Implementierung durch WZ-IT.

Weiterführende Guides

• Was ist LiteLLM?, Aufgabe und Aufbau des Gateways im LLM-Stack.
• Model Context Protocol im Unternehmen, wie MCP funktioniert und welche Risiken stdio-Server mitbringen.
• n8n-Sicherheitsupdate September 2026, Versionsmatrix und Härtung für n8n.
• Bleeding Llama (CVE-2026-7482), was die Ollama-Lücke über den Betrieb lokaler KI zeigt.
• CVE-Monitoring für Self-Hosted Software, wie Schwachstellen strukturiert verfolgt werden.
• Europäische LLM-APIs im Vergleich, Anbieter hinter einem Gateway kombinieren.
• Langfuse für LLM-Observability, Modellaufrufe nachvollziehbar protokollieren.
• KI-Lösungen von WZ-IT, der Hub mit allen Angeboten zu lokaler KI und LLM-Betrieb.

LiteLLM-Version prüfen lassen? Wir gleichen Ihre Installation mit dem Advisory ab, spielen das Update ein und härten das Gateway nach der Checkliste. Termin vereinbaren

Quellen

• GitHub Security Advisory GHSA-7hp6-4w63-5g45, LiteLLM
• GitHub Security Advisory GHSA-hhww-mrg2-969h, LiteLLM
• LiteLLM, Security Advisories
• LiteLLM, Releases
• LiteLLM, Release v1.100.4
• LiteLLM, Release v1.101.4
• LiteLLM, Release v1.103.2
• LiteLLM, Quellcode user_api_key_auth.py
• LiteLLM Docs, Production Best Practices
• LiteLLM Docs, Access Control
• LiteLLM Docs, MCP
• LiteLLM, Security Update März 2026
• CISA, Known Exploited Vulnerabilities Catalog
• NVD, CVE-2026-42208
• NVD, CVE-2026-42271
• NVD, CVE-2026-59822