LiteLLM 1.107.0 war Schadcode: Wer latest gezogen hat, muss Schlüssel tauschen

LiteLLM ist ein Gateway, das viele Modellanbieter hinter einer API bündelt. Am 21. Oktober 2026 hat jemand eine manipulierte Version 1.107.0 auf PyPI und als Docker-Image veröffentlicht. Sie liest Zugangsdaten aus und schickt sie an einen fremden Server. Betroffen ist, wer die Version in diesem Zeitfenster installiert oder einen Tag wie latest gezogen hat. Dieser Beitrag trennt, was mehrere unabhängige Quellen bestätigen, was nur LiteLLM selbst sagt und was wir daraus ableiten.

Zeitfenster am 21. Oktober 2026

Verifiziert (LiteLLM und Datadog stimmen überein): Nur 1.107.0 ist betroffen, 1.106.2 ist die letzte sichere Version. Auf PyPI lagen alle sieben Wheels laut LiteLLM von 11:39:51 bis 13:23 UTC, Datadog nennt die Quarantäne um 13:20.

Vom Hersteller behauptet (LiteLLM): Die Docker-Tags v1.107.0, latest, main-latest und main-stable zeigten von 11:46:56 bis 14:20 UTC auf ein manipuliertes Image. Bei GHCR waren dieselben Tags laut LiteLLM bis 13:51 unerreichbar. Datadog gibt als Zeitpunkt der Entfernung 13:53 an. Wer sicher gehen will, rechnet mit dem weitesten Fenster.

Was der Schadcode tut

Das Paket bringt die Dateien cook.pth und cook.py (Stealer) sowie sitecustomize.py (Fernzugriff) in site-packages mit. Eine .pth-Datei wird beim Start des Interpreters ausgeführt. Datadog schreibt dazu: Jeder Python-Prozess in der Umgebung führt die Schadsoftware aus, selbst wenn LiteLLM nie importiert wird.

Nach den Berichten von Datadog und The Register (verifiziert) sammelt der Stealer:

• Cloud-Zugänge für AWS, GCP und Azure
• Secrets aus Kubernetes, Docker, Vault und Terraform
• SSH- und GPG-Schlüssel, .env-Dateien, Shell-Verlauf
• API-Schlüssel von LLM-Anbietern, einschließlich der Provider-Keys in der Proxy-Datenbank

The Register beschreibt die Übertragung: Die Daten werden mit AES-256-CBC verschlüsselt, der Schlüssel mit RSA-4096 verpackt, dann geht ein POST an www[.]litellm[.]dev/healthcheck. Das ist eine Lookalike-Domain.

Vom Hersteller behauptet: Die offizielle Quelle auf GitHub enthalte die Schadsoftware nicht. Die Artefakte seien aus einem Repository mit fast gleichem Namen gebaut worden (Berri-AI/litellm, ein Bindestrich). The Register und Datadog beschreiben das Lookalike-Repository ebenfalls.

Datadog beobachtete außerdem, dass der Fernzugriff stündlich eine Datei in einem GitHub-Repository abfragt, die eine Domain nennt, von der Code nachgeladen und ausgeführt würde. Diese Datei habe nur Testwerte enthalten, es sei keine zweite Stufe in freier Wildbahn aufgetaucht. Das ist eine Aussage von Datadog über den Beobachtungszeitraum, keine Garantie für die Zukunft.

Wie es dazu kam (Angabe des Herstellers)

LiteLLM nennt im Bericht vom 23. Oktober als Ursache gestohlene GitHub-CLI-Tokens von drei Konten (ein Organisationsinhaber, zwei Maintainer). Das erste Token stamme aus einem Agent-Platform-Master-Key, der am 27. Mai in einem öffentlichen Repository gelandet und nie widerrufen worden sei. Der erste Bericht hatte noch interne Deployment-Logs vermutet und wurde korrigiert. Diese Kette stammt allein vom Hersteller.

Es ist der zweite Vorfall bei LiteLLM in diesem Jahr: Früher in diesem Jahr waren die Versionen 1.82.7 und 1.82.8 manipuliert (Datadog nennt keinen Monat). Datadog schreibt, ein Zusammenhang sei zum Zeitpunkt des Berichts nicht festgestellt. Wir führen beide Fälle deshalb getrennt. Zum Ausmaß: The Register nennt etwa 23 Millionen Downloads pro Woche (Angabe von The Register, nur als Größenordnung).

Prüfen: Waren wir im Fenster?

1. Version vergleichen. pip show litellm im Container oder in der Umgebung, docker image ls --digests auf dem Host. Zu vergleichen sind Version 1.107.0 und der Index-Digest, den LiteLLM im Bericht nennt.
2. Zeitraum ansehen. Pull-Protokolle, CI-Läufe und Image-Verlauf vom 21. Oktober zwischen 11:39 und 14:20 UTC.
3. Indikatoren suchen. /tmp/.pc_once_* (laut The Register ein Hinweis, dass die Übertragung schon gelaufen ist) und /tmp/remote_code_loader.lock. Außerdem cook.pth und cook.py im Dateisystem. LiteLLM weist darauf hin, dass fehlende Spuren nicht beweisen, dass die Umgebung sauber ist.

Wer heute latest zieht, bekommt abgeleitet aus den Tag-Zeiten kein Schadcode-Image mehr, weil die Tags bis spätestens 14:20 UTC zurückgesetzt waren. Gefährdet sind Pulls im Fenster und Umgebungen, die seitdem unverändert laufen.

Bei einem Treffer

Eine betroffene Umgebung wird neu aufgebaut. Das Löschen des LiteLLM-Verzeichnisses entfernt die Payload nicht, und jeder Aufruf von python oder pip löst sie erneut aus (Datadog und LiteLLM). Der Ablauf, den der Hersteller empfiehlt:

1. Host isolieren, laufende Daemons der Schadsoftware beenden.
2. cook.pth, cook.py und sitecustomize.py entfernen, besser die Umgebung komplett neu bauen.
3. Von einem sauberen Rechner aus rotieren: die IAM-Rolle der Instanz, jeden Provider-Key in der Proxy-Datenbank, Master- und Virtual Keys, das Passwort in DATABASE_URL und jedes Secret, das als Umgebungsvariable gesetzt war.
4. In CloudTrail nach GetCallerIdentity-Aufrufen suchen (Empfehlung von LiteLLM).

Unser eigener Stand

Wir haben am 24. Oktober 2026 nur lesend nachgesehen, nichts verändert. Auf dem Host, der unser Chat-Frontend und den LiteLLM-Router betreibt, läuft ghcr.io/berriai/litellm:v1.100.4, Image gebaut am 3. Oktober, Container zuletzt am 20. Oktober gestartet, im Container ist litellm-1.100.4 installiert. Auf dem Host der TMS-Oberfläche läuft v1.106.1. Dieser Container wurde am 21. Oktober um 06:44 UTC angelegt, rund fünf Stunden vor dem ersten bösartigen Upload um 11:39.

In beiden Containern gibt es weder /tmp/.pc_once_* noch /tmp/remote_code_loader.lock, und find über das Container-Dateisystem fand kein cook.pth und kein cook.py. Eine sitecustomize.py liegt nur in den Paketen ddtrace und opentelemetry; im Wurzelverzeichnis von site-packages liegt keine. Beide Instanzen nutzen feste Tags statt latest. Das /tmp der Hosts selbst haben wir nicht geprüft. Ergebnis: kein Befund, beide Instanzen waren außerhalb des Fensters.

Was sich ändern lässt

Feste Tags oder Digests statt latest und main-*; sie sind die Versicherung, die bei diesem Vorfall funktioniert hat. Das Gateway sollte nur die Ziele erreichen, die es braucht, denn eine Übertragung nach außen scheitert an einer Egress-Sperre. Provider-Keys gehören eng zugeschnitten und mit Budget in die Datenbank, damit ein Diebstahl begrenzt bleibt. Neue Versionen erst nach einigen Tagen Wartezeit übernehmen: Diese Version war nach rund zwei Stunden gesperrt.

Weiterführende Quellen

• LiteLLM: Security Incident, 21. Oktober 2026: Zeitleiste, Digests, Rotationsliste (Hersteller)
• LiteLLM: Attack Chain: Ursache laut Hersteller, Korrektur vom 23. Oktober
• Datadog Security Labs: LiteLLM compromised on PyPI and Docker: Payload, Zeitfenster, Bereinigung
• The Register: LiteLLM supply chain attack hoovers up passwords and secrets: Verschlüsselung, Zieladresse, Indikatoren
• Simple Icons: pypi.svg und docker.svg: Markenzeichen, CC0
• Eigene Prüfung am 24. Oktober 2026 (nur lesend, siehe Abschnitt Unser eigener Stand): Versionen, Image-Daten, Dateisuche in den Containern