LiteLLM 1.107.0 kompromittiert: Stealer in PyPI-Paket und Docker-Images

Die am 21. Oktober 2026 veröffentlichte LiteLLM-Version 1.107.0 war manipuliert. Alle sieben PyPI-Wheels und die offiziellen Docker-Images enthielten einen Credential Stealer und einen Nachlader für Fremdcode. Der Schadcode startet bei jedem Start des Python-Interpreters, ein Import von LiteLLM ist nicht nötig. PyPI hat die Version entfernt, das Image v1.107.0 ist gelöscht, die übrigen Tags zeigen laut LiteLLM nicht mehr auf das verseuchte Image. Aktuell ist wieder 1.106.2.

Betroffen ist, wer 1.107.0 per pip installiert oder ein betroffenes Image im Zeitfenster gestartet hat. Nicht betroffen sind Installationen mit fest gepinnter älterer Version und Enterprise-Kunden aus der privaten Registry von LiteLLM. Wer betroffen ist, muss heute handeln: Das System gilt als kompromittiert, alle erreichbaren Zugangsdaten sind zu rotieren.

Was ist passiert?

Laut Vorfallbericht von LiteLLM wurde die Release-Pipeline kompromittiert. Director of Security Oliver Jensen schreibt im GitHub-Issue, die Aktionen liefen über die GitHub-Konten von drei Engineers, offenbar mit gestohlenen OAuth-Tokens der GitHub-CLI. Mit einem Konto wurde der Release-Workflow gestartet, mit einem anderen genehmigt. Ein Token gehörte einem Organisationsinhaber, damit wurden Branch-Schutzregeln abgeschaltet. Gebaut wurde aus dem Lookalike-Repository Berri-AI/litellm statt BerriAI/litellm, der Git-Tag v1.107.0 selbst ist sauber.

Die Tokens stammen nach bisherigem Stand aus Logs einer internen, aus dem Internet erreichbaren LiteLLM-Instanz. LiteLLM vermutet als Einfallstor eine kürzlich gepatchte Schwachstelle, bestätigt ist das noch nicht. Alle beteiligten Tokens wurden widerrufen, reguläre Releases sind pausiert. Es ist bereits der zweite Vorfall dieses Jahres, über den Angriff auf die März-Releases hat S-EDV berichtet.

Wer ist betroffen?

Laut LiteLLM betroffen sind:

• PyPI: litellm==1.107.0, alle sieben Wheels, online von 11:39 bis 13:23 Uhr UTC.
• Docker Hub: litellm/litellm mit den Tags v1.107.0, latest, main-latest und main-stable von 11:46 bis 14:20 Uhr UTC.
• GHCR: ghcr.io/berriai/litellm, litellm-database und litellm-non_root mit denselben Tags von 11:46 bis spätestens 13:51 Uhr UTC.

Kritisch sind damit vor allem Proxy-Container, die ungepinnt latest oder main-stable ziehen, sowie CI-Runner und Entwicklerrechner mit ungepinnter Installation. Die Releases 1.106.2, 1.107.0rc1 und rc2 sind laut Upwind und SafeDep sauber.

Wie kritisch ist das?

Sehr kritisch. Die Datei cook.pth lädt laut StepSecurity und Issue-Analyse den Stealer „privcollect“. Er sammelt SSH- und GPG-Schlüssel, Cloud-Zugangsdaten inklusive Instanzrollen, Browser-Passwörter, Tokens von KI-Werkzeugen, die Umgebungsvariablen aller lesbaren Prozesse und bei gesetztem DATABASE_URL alle im Proxy gespeicherten Provider-Schlüssel. Die Daten gehen verschlüsselt an litellm.dev, eine Domain, die nicht zum Projekt gehört. Zusätzlich startet sitecustomize.py einen Daemon, der stündlich über einen GitHub-Dead-Drop eine Serveradresse abfragt und von dort Python-Code nachladen und ausführen kann. Wer die Version mit Internetzugang ausgeführt hat, sollte vom Abfluss der Daten ausgehen. Das Sicherheitsunternehmen Wiz meldete im Issue bereits beobachtete Post-Exploitation-Aktivitäten.

Was sollten Admins jetzt tun?

• Inventar prüfen: pip show litellm in allen Umgebungen, bei Containern den Digest mit docker images --digests ermitteln. Der betroffene Index-Digest auf Docker Hub lautet sha256:1bbcb1443bc9….
• In jedem site-packages nach cook.pth, cook.py, sitecustomize.py und litellm-1.107.0.dist-info suchen, außerdem nach /tmp/remote_code_loader.lock. Ein Fund belegt die Kompromittierung, kein Fund beweist laut LiteLLM nichts.
• Nicht mit pip install beginnen, denn jeder Python-Start führt den Schadcode erneut aus. Dateien aus der Shell löschen, den Daemon beenden, Umgebung oder Image besser komplett neu bauen.
• Alle Secrets rotieren, die das System erreichen konnte: Provider-Schlüssel im Proxy, Master- und Virtual Keys, Datenbankpasswort, Instanzrollen, SSH-Schlüssel, CI- und Vault-Tokens.
• Auf litellm==1.106.2 pinnen, Images per Digest statt per Tag referenzieren und Python-Abhängigkeiten mit pip install --require-hashes installieren.
• Verbindungen zu litellm.dev blockieren und in Logs suchen, bei AWS zusätzlich CloudTrail auf GetCallerIdentity prüfen.

Einordnung für Unternehmen

Ein LLM-Gateway bündelt die teuersten Schlüssel eines Unternehmens. Genau diese Rolle macht LiteLLM zum attraktiven Ziel, wie schon die offen erreichbaren Gateways gezeigt haben. Der Fall belegt zudem, dass eine gehärtete Pipeline mit signierten Images nicht hilft, wenn Entwickler-Tokens abfließen. Für Anwender heißt das: Floating Tags wie latest gehören nicht in produktive Compose-Dateien, Updates sollten mit festen Versionen und geprüften Digests erfolgen.

Passende Anleitungen auf S-EDV

• LiteLLM als LLM-Gateway mit Docker: Aufbau, Konfiguration und Update-Weg.
• Docker Compose absichern: Secrets statt Klartext und feste Image-Versionen.

Quellen

• GitHub-Issue 47826 im Repository BerriAI/litellm mit Statusmeldungen von LiteLLM (21.10.2026)
• LiteLLM: Vorfallbericht zum 21. Oktober 2026
• The Hacker News: LiteLLM in Supply-Chain-Angriff kompromittiert
• StepSecurity: Analyse der manipulierten Version 1.107.0
• Socket: Analyse von PyPI-Paket und Docker-Images
• SafeDep: Analyse von Stealer und Backdoor