Kompromittiertes LiteLLM 1.107.0 auf PyPI stahl Zugangsdaten und installierte eine Hintertür

Michael Dobler

Autor Dr. Web

22. Okt. 2026

2 Min. Lesezeit

Die Python-Bibliothek LiteLLM, die Anwendungen mit über 100 Sprachmodellen verbindet, lag am 21. Oktober knapp zwei Stunden lang als manipulierte Version 1.107.0 bei PyPI. Der eingeschleuste Code sammelt Zugangsdaten vom SSH-Schlüssel bis zum Cloud-Konto und lädt stündlich weiteren Code nach. Gebaut und signiert hat das Paket die offizielle Release-Pipeline des Projekts.

Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügen

Eine Datei mit zwölf Byte genügt: cook.pth enthält nur die Zeile „import cook“, und Python führt die Datei bei jedem Start aus, auch wenn ein Programm LiteLLM gar nicht nutzt.^[1] Laut PyPI-Statistik wird LiteLLM rund 3,4 Millionen Mal am Tag heruntergeladen.^[6]

Auf einen Blick

Das Wichtigste in Kürze

Betroffen sind litellm 1.107.0 bei PyPI von 13:39 bis 15:23 Uhr MESZ, vier Docker-Tags bis 16:20 Uhr.
Version 1.106.2 und alle älteren Versionen gelten als sauber.
Betreiber mit installierter Version 1.107.0 sollten alle vom Rechner erreichbaren Zugangsdaten wechseln.
Die Angreifer nutzten gestohlene GitHub-Zugänge von drei Entwicklern.

Wie kam der Schadcode in das offizielle Paket?

Dose mit Aufschrift „Geprüft“ und Siegel „AMT BEWERTET“ auf Weiß — Angreifer nutzten GitHub-Token von drei Entwicklern, um Branch-Schutz zu deaktivieren, Release-Workflow zu manipulieren und Protokolle zu löschen

Nach dem Vorfallbericht von LiteLLM besaßen die Angreifer GitHub-CLI-Zugangstoken von drei Entwicklern. Mit dem Token eines Administrators der GitHub-Organisation hoben sie den Branch-Schutz auf und änderten den Release-Workflow so, dass er aus dem Doppelgänger-Repository Berri-AI/litellm statt BerriAI/litellm baute. Ein zweites Token erteilte die Freigabe, ein drittes löschte danach die Protokolle der Läufe.^[2] Die Token stammen nach jetzigem Stand aus den Logs einer internen, offen im Netz erreichbaren LiteLLM-Instanz. Dorthin gelangten die Token nach Darstellung des Unternehmens, weil Claude Code solche Token in bestimmten Fällen in Antworten einbette. LiteLLM prüft das noch.

Das Paket legt neben cook.pth die Dateien cook.py und sitecustomize.py ab. Der Datendieb greift auf 16 Datenquellen zu, darunter gespeicherte Browser-Passwörter, AWS-, Azure- und Google-Cloud-Zugänge, Kubernetes-Konfigurationen sowie Einstellungen von Claude Code, Cursor und Copilot. Die zweite Datei startet einen Hintergrundprozess, der stündlich eine Serveradresse aus einem GitHub-Konto holt und von dort Code ausführt. Das Konto war zwei Stunden nach dem Upload gelöscht, bis dahin konnte weiterer Code nachkommen.^[1]

Warum half die Signatur nicht?

Nach dem ersten Angriff auf LiteLLM im März verlegte das Team die Releases in ein privates Repository, stellte auf Trusted Publishing um, bei dem PyPI nur Uploads aus einer festgelegten Build-Umgebung annimmt, und signierte fortan Docker-Images.^[2] Eine solche Signatur belegt nach der PyPI-Dokumentation, woher ein Paket stammt, aber nicht, ob man ihm trauen kann. Schadcode, der vor oder während des Builds hineingerät, trägt dieselbe gültige Signatur.^[3] Im Mai trugen auch die manipulierten Versionen von 42 TanStack-Paketen gültige Herkunftsnachweise.

Ein signiertes Paket aus der offiziellen Pipeline kann trotzdem fremden Code enthalten. Ein paar Tage Wartezeit hätten hier gereicht.
Markus Seyfferth, Chefredakteur Dr. Web

Der LiteLLM-Vorfall in Zahlen

Wie lange die manipulierte Version 1.107.0 verfügbar war und was der Schadcode ausliest

knapp 2 Std.

lag die manipulierte Version bei PyPI, Docker-Images noch rund eine Stunde länger

gestohlene GitHub-Zugänge von Entwicklern genügten für Workflow, Freigabe und Spurenbeseitigung

Datenquellen liest der Datendieb aus, von SSH-Schlüsseln bis zu Browser-Passwörtern

3,4 Mio.

Downloads von LiteLLM an einem Tag laut PyPI-Statistik

Ablauf am 21. Oktober (MESZ)

12:08 UhrBranch-Schutz mit Administrator-Token aufgehoben

SchrittRelease-Workflow geändert

Quelle des BuildsDoppelgänger-Repository

13:39 Uhrsieben Installationspakete für Linux, macOS, Windows

SchrittUpload zu PyPI

Statusoffiziell signiert

13:46 Uhrv1.107.0, latest, main-latest, main-stable

SchrittDocker-Images veröffentlicht

StatusDocker Hub und GHCR

15:23 UhrPyPI

SchrittVersion entfernt

Statusbereinigt

16:20 UhrDocker Hub

SchrittTags entfernt oder umgestellt

Statusbereinigt

Was müssen Betreiber jetzt tun?

LiteLLM rät, eine betroffene Umgebung nicht mit pip zu reparieren, weil jeder Python-Start den Schadcode erneut auslöst.^[2]

Prüfen: Suchen Sie in site-packages nach cook.pth, cook.py und sitecustomize.py. Ein fehlender Fund beweist nichts, weil Container und Aufräumskripte Spuren löschen.
Bereinigen: Löschen Sie die Dateien aus der Shell, beenden Sie den Hintergrundprozess und bauen Sie Umgebung oder Image mit litellm 1.106.2 neu.
Zugangsdaten wechseln: Dazu zählen die Cloud-Berechtigungen, mit denen der Server arbeitet, alle in der LiteLLM-Datenbank gespeicherten Schlüssel für Sprachmodell-Dienste und das Datenbank-Passwort.
Wartezeit einbauen: uv kennt die Option exclude-newer mit dem Wert 7 days, pip die Option --uploaded-prior-to P3D.^[4]^[5] GitHubs Dependabot wartet seit Juli drei Tage.

Weil der Datendieb auch Browser-Passwörter und Verlauf ausliest, kann ein Befall die Meldepflicht gegenüber der Datenschutzaufsicht binnen 72 Stunden nach Art. 33 DSGVO auslösen.^[7] Für den 27. Oktober kündigt LiteLLM zudem die Offenlegung einer weiteren Sicherheitslücke an, deren Korrektur bisher nur Enterprise-Kunden erhalten.