LiteLLM-Lücken: Ein einfaches Benutzerkonto reichte zur Übernahme des Gateways

Bei LiteLLM, dem Open-Source-Gateway für Sprachmodelle, konnte ein authentifiziertes Konto mit geringen Rechten die Laufzeitkonfiguration des Proxys überschreiben. Der Angreifer brauchte dafür keine Administratorrolle und keinen Zugang zu dem Rechner, auf dem der Proxy läuft.

Check Point Research hat die Ergebnisse am 13. Oktober 2026 in einer Analyse von Version 1.77.7^[1] veröffentlicht. Die Lücken tragen die Kennungen CVE-2026-35029 und CVE-2026-59823. Version 1.83.9 behebt sie.

Der Bericht beschreibt eine Sicherheitsprüfung und nennt keinen Fall aktiver Ausnutzung. Auch IT Security Guru^[2] hat darüber berichtet.

Eine fehlende Prüfung bei /config/update

LiteLLM ist ein Open-Source-Projekt aus dem Umfeld von Y Combinator. Es bietet ein SDK und ein Gateway, das Aufrufe an mehrere Modellanbieter verteilt.

Das Gateway sitzt zwischen den Anwendungen und den Anbietern. Es verwahrt die API-Schlüssel, entscheidet, wohin jede Anfrage geht, und führt Logs und Nutzungslimits.

Laut Check Point fehlte dem Endpunkt /config/update eine Prüfung der Berechtigungen. Jeder authentifizierte Nutzer konnte die aktive Konfiguration des Proxys ändern. Aus dieser Änderung leiten die Forscher drei Folgen ab.

• Auslesen beliebiger Dateien auf dem Server.
• Übernahme des Administratorkontos.
• Ausführung von Code aus der Ferne über bösartige Python-Module, die aus einem Cloud-Speicher geladen werden.

Die zweite Lücke steckt in der Funktion „Clientside LLM Credentials“. Check Point stuft sie als SSRF ein, also als Anfrage, die der Server im Auftrag des Angreifers ausführt. Über diese Lücke landeten die API-Aufrufe samt den Schlüsseln der Anbieter bei einem Ziel, das der Angreifer bestimmte.

Die Konfiguration bestimmt, welcher Code läuft

Die eigentliche Ursache ist eine einzige.

LiteLLM behandelte die Konfiguration als bloße Daten. Im Proxy legt die Konfiguration aber auch fest, welche Python-Module geladen werden.

Ein Feld, das auf ein Modul verweist, ist damit gleichbedeutend mit einer Ausführungsberechtigung. Wer dieses Feld beschreibt, bringt Code auf dem Proxy zur Ausführung.

Das Gateway vergrößert den Schaden. Im selben Prozess liegen die Schlüssel aller Anbieter, die Routing-Regeln und die Benutzerkonten. Eine fehlende Berechtigung an einem Endpunkt wird so zum Zugang zu jedem Modell, das im Unternehmen genutzt wird.

Check Point schließt seine Zusammenfassung mit dem Hinweis auf zwei Grundlagen der Sicherheit: Zugriffskontrolle und Eingabevalidierung. Es ist derselbe Fehler wie bei den Webanwendungen der frühen 2000er-Jahre, nur steckt er heute in der Komponente, die alle Schlüssel verwahrt.

Drei Fragen für alle, die LiteLLM produktiv einsetzen

1. Welche Version läuft derzeit? Versionen vor 1.83.9 sind beiden Lücken weiterhin ausgesetzt.
2. Wer hat ein Konto auf dem Proxy? Jeder authentifizierte Nutzer war ein potenzieller Administrator. Die Kontenliste ist also eine Liste von Personen mit Zugriff auf die Schlüssel.
3. Wurden die Anbieterschlüssel nach dem Update rotiert? Der Patch schließt die Lücke, doch zuvor ausgelesene Schlüssel bleiben bis zu ihrem Widerruf gültig.

Das Gateway gehört zum Identitätsperimeter

Ein LLM-Gateway ist erst dann produktionsreif, wenn es die Rollen trennt. Logs lesen, ein Modell nutzen und die Konfiguration ändern sind drei verschiedene Berechtigungen.

Version 1.83.9 schließt die beiden CVEs. Das Architekturrisiko bleibt, denn jedes Gateway bündelt dieselben Schlüssel an derselben Stelle.

Aus diesem Fall ergeben sich sechs konkrete Schritte.

• LiteLLM auf Version 1.83.9 oder neuer aktualisieren.
• Alle im Proxy verwahrten API-Schlüssel der Anbieter rotieren.
• Die Konten auf dem Proxy überprüfen und inaktive Konten schließen.
• Den Endpunkt /config/update auf das Netz der Administratoren beschränken.
• Die Netzwerkziele begrenzen, die der Proxy aufrufen darf, um die Angriffsfläche für SSRF zu verkleinern.
• Anbieter kommerzieller Gateways fragen, wie sie Konfigurations- von Nutzungsrechten trennen, und dies vertraglich festhalten.

Wer das Sicherheitsbudget verantwortet, findet hier einen neuen Posten. Das Gateway muss denselben Audits unterzogen werden wie das Identitätssystem des Unternehmens.