LiteLLM: Release-Pipeline gehackt, Version 1.107.0 verteilte Passwort-Stealer

Worum es geht

LiteLLM ist ein quelloffenes Python-SDK und ein „KI-Gateway“: Anwendungen sprechen über eine einheitliche Schnittstelle mit Modellen verschiedener Anbieter. Das Projekt ist enorm verbreitet – laut BleepingComputer hat es rund 61.800 GitHub-Sterne und 92 Millionen monatliche Downloads auf PyPI (dem Paketverzeichnis für Python). Genutzt wird es unter anderem von NVIDIA, Netflix, AT&T und Okta.

Am 21. Oktober wurde die Release-Pipeline des Projekts gekapert. Ein Angreifer veröffentlichte Version 1.107.0 auf PyPI und in den Docker-Registries. Laut dem Maintainer enthielt sie „kompilierte Malware, die Zugangsdaten stiehlt und Werkzeuge zur Remote-Code-Ausführung nachlädt“. Das nennt man einen Supply-Chain-Angriff (Lieferkettenangriff): Nicht das Zielsystem wird direkt gehackt, sondern Software, der es vertraut.

Betroffene Artefakte und Zeitfenster

• PyPI: litellm==1.107.0, alle sieben Wheels (fertige Installationspakete), online von 11:39 bis 13:23 UTC.
• Docker Hub: v1.107.0, latest, main-latest und main-stable zeigten von 11:46 bis 14:20 UTC auf ein kompromittiertes Image.
• GHCR (GitHub Container Registry): dieselben Tags für litellm, litellm-database und litellm-non_root, ab 11:46 UTC bis zur Sperrung gegen 13:51 UTC.

Wer also an diesem Tag „latest“ gezogen hat, kann betroffen sein. Mehrere Sicherheitsfirmen erkannten den Angriff laut BleepingComputer innerhalb von sechs Minuten nach Veröffentlichung.

Wie die Malware funktioniert

Der Angreifer änderte den Anwendungscode nicht, sondern nur das Installationspaket. Es legte drei Dateien im Python-Bibliotheksverzeichnis ab: cook.pth, cook.py und sitecustomize.py. Python führt beim normalen Start ausführbare Zeilen in .pth-Dateien aus und importiert sitecustomize. Dadurch läuft die Schadsoftware bei jedem Python-Start – auch wenn die Anwendung LiteLLM gar nicht importiert. Selbst Python oder pip zur Untersuchung zu starten, löst die Malware erneut aus.

Gesucht wurde nach:

• Cloud- und Deployment-Zugangsdaten (AWS, Azure, Google Cloud, Kubernetes, Docker)
• KI-Zugangsdaten sowie in LiteLLM gespeicherte Provider-Schlüssel und Modelleinstellungen
• Entwicklergeheimnissen: Git, GitHub, npm, PyPI, CI/CD (GitLab, Jenkins), .env-Dateien, SSH-, GPG- und TLS-Schlüssel
• Browserdaten (Logins, Cookies, Autofill, Verlauf)
• Umgebungsvariablen, Shell-Verläufe, System- und Netzwerkinformationen

Die Daten werden mit AES-256-CBC verschlüsselt, der Schlüssel mit RSA-4096, und dann an litellm[.]dev/healthcheck hochgeladen. Zusätzlich startet sitecustomize.py einen abgekoppelten Loader, der stündlich einen auf GitHub gehosteten Verweis prüft und Python-Code von einem externen Server ausführt. Laut Aikido ist das praktisch ein Remote-Access-Trojaner: Die Angreifer können auch nach dem Diebstahl weiter Befehle ausführen.

Wie die Angreifer hineinkamen

Laut Incident-Report von LiteLLM nutzten die Angreifer gestohlene GitHub-Zugangsdaten dreier Entwicklerkonten. Damit änderten sie den Release-Workflow und leiteten ihn auf ein täuschend ähnliches, vom Angreifer kontrolliertes Repository um. Die Zugangsdaten stammen möglicherweise aus Logs einer aus dem Internet erreichbaren internen LiteLLM-Installation. Das Projekt nennt außerdem Umstände, unter denen Claude Code GitHub-Tokens in Antworten preisgeben konnte, die LiteLLM dann protokollierte. Wie die Angreifer ursprünglich Zugriff auf diese Installation bekamen, ist nicht geklärt.

Brisant: Nach dem Angriff im März (damals über den Sicherheitsscanner Trivy von Aqua Security, den LiteLLM in der CI/CD-Pipeline nutzte; die Gruppe TeamPCP veröffentlichte schädliche Versionen) hatte das Projekt Releases in ein privates Repository verlegt und signierte Docker-Images eingeführt. Diesmal signierte der manipulierte Workflow die Schadsoftware selbst. Eine gültige Signatur belegt nur, dass ein Artefakt seit dem Signieren unverändert ist – nicht, dass der Code beim Signieren harmlos war.

Was Betroffene tun sollten

• Betroffene Deployments stoppen und Umgebungen untersuchen, ohne den Python-Interpreter oder pip zu starten.
• Infizierte Systeme isolieren und aus sauberen Backups neu aufbauen; vorher forensische Spuren sichern.
• Alle erreichbaren Geheimnisse sofort rotieren (Cloud, CI/CD, Provider-Keys).
• Das bloße Löschen des LiteLLM-Verzeichnisses reicht nicht, Startdateien oder der Loader können bleiben.
• Empfohlene Version: LiteLLM 1.106.2. Kunden der privaten Enterprise-Registry waren laut Projekt nicht betroffen.
• Pakete und Image-Digests in Produktion, auf Entwicklerrechnern und CI-Runnern prüfen; Logs auf missbräuchliche Nutzung der Zugangsdaten durchsehen und KI-Nutzungsdaten mit Cloud-Audit-Logs abgleichen.

Einordnung

Ein KI-Gateway bündelt Schlüssel für viele Modelle und Dienste und ist daher ein lohnendes Ziel. Sakshi Grover (IDC) sagt, es sei privilegierte Infrastruktur: Zentralisierung verbessere die Governance, konzentriere aber auch Vertrauen. Keith Prabhu (Confidis) betont, dass ein vertrauenswürdiges Quell-Repository nicht garantiert, dass das installierte Paket daraus gebaut wurde. Empfohlen werden verifizierbare Build-Herkunft (Provenance), besser geschützte Publishing-Zugangsdaten, Beschränkung auf geprüfte Digests und unabhängige Freigabe für Änderungen an Release-Workflows.

Offen bleibt, wie viele Systeme tatsächlich infiziert wurden und wie der Erstzugriff erfolgte. Fehlende Indikatoren beweisen laut Grover nicht, dass eine Umgebung sauber ist. Das kurze Zeitfenster von rund zwei Stunden begrenzt das Risiko, doch bei 92 Millionen Monatsdownloads ist es nicht vernachlässigbar.