LiteLLM-Release-Pipeline erneut gekapert: Infostealer als v1.107.0 auf PyPI und Docker Hub
Am Morgen des 21. Oktober 2026 landete ein bösartiges LiteLLM-Release auf PyPI und in den offiziellen Docker-Images des Projekts. Version 1.107.0 trug einen Credential Stealer und einen Remote-Code-Loader statt des Codes, den ihre Maintainer geschrieben hatten. Laut dem eigenen Security-Update von LiteLLM wurde die Release-Pipeline selbst kompromittiert — mit geleakten GitHub-Credentials aus Entwicklerkonten des Projekts. Die manipulierten Wheels standen kaum zwei Stunden auf PyPI, die verseuchten Docker-Tags überdauerten den ganzen Nachmittag. In einem Ökosystem aus automatisierten Builds und gepinnten Abhängigkeiten war das mehr als genug Zeit, um Folgen zu haben.
Ein sauberer Tag, ein vergifteter Build
Die Offenlegung liest sich wie eine Checkliste dafür, wie zerbrechlich Vertrauen in Pakete ist. LiteLLM berichtet, der Angreifer habe GitHub-CLI-OAuth-Tokens aus drei Entwicklerkonten erlangt — offenbar aufgezeichnet in den Logs einer internetexponierten internen LiteLLM-Instanz; eines der Konten gehörte einem GitHub-Organisationsinhaber. Mit diesen Credentials wurde der Branch-Schutz außer Kraft gesetzt, eine Workflow-Änderung erzwungen gepusht und die Release-Pipeline auf ein Lookalike-Repository gelenkt: Berri-AI/litellm, nur ein Bindestrich vom echten BerriAI/litellm entfernt. Der offizielle Git-Tag zu v1.107.0 blieb sauber; die bösartigen Artefakte wurden aus dem Schein-Repository kompiliert.„Diese Version enthielt kompilierte Malware, die Zugangsdaten stiehlt und Werkzeuge zum Ausführen entfernten Codes nachlädt.“ — LiteLLM-Security-Update, 21. Oktober 2026Immerhin war die Erkennung schnell. Wie BleepingComputer berichtet, markierten Sicherheitsfirmen darunter Socket und Endor Labs das Release innerhalb von rund sechs Minuten, und PyPI hatte die Wheels bis 13:23 UTC entfernt; Docker Hub wurde am späten Nachmittag bereinigt. LiteLLM zufolge waren Kunden der privaten Enterprise-Registry nicht betroffen. Sechs Minuten zählen trotzdem, wenn ein Paket rund 92 Millionen Downloads pro Monat verzeichnet und Firmen wie NVIDIA, Netflix und Okta zu seinen Nutzern zählen, so BleepingComputer.
Was der Stealer einsammelt
Die Technik der Payload erklärt, warum die Empfehlungen so unmissverständlich ausfallen. Die Wheels legten drei Dateien — cook.pth, cook.py und sitecustomize.py — im site-packages-Verzeichnis von Python ab. Python führt diese Dateitypen bei jedem Interpreterstart aus, daher lief jeder Python-Prozess auf der Maschine die Malware aus, selbst wenn LiteLLM nie importiert wurde. Der technische Bericht von Datadog Security Labs ergänzt, dass die Deinstallation des litellm-Pakets die Dateien nicht entfernt; sie müssen von Hand gelöscht werden. Kodems Incident-Analyse dokumentiert, was der Stealer einsammeln sollte:- Cloud- und Infrastruktur-Credentials: AWS-, Azure- und GCP-Keys inklusive Instance-Metadata-Tokens, dazu Kubernetes-, Docker- und Terraform-Secrets
- KI-spezifisches Material: LLM-Provider-API-Keys, in der LiteLLM-Proxy-Datenbank gespeicherte Zugangsdaten und Session-Dateien von KI-Coding-Tools
- Entwickler- und Registry-Tokens: Git-Credentials, GitHub-, npm- und PyPI-Tokens, SSH-, GPG- und TLS-Keys
- Lokale Secrets: .env-Dateien, Umgebungsvariablen, Shell- und Datenbank-Histories
- Browserdaten: gespeicherte Passwörter, Cookies und AutoFill-Einträge
Zweiter Pipeline-Vorfall im Jahr
Es ist die zweite kompromittierte LiteLLM-Release in 2026. Im März hatte ein als TeamPCP bekannter Akteur die Versionen 1.82.7 und 1.82.8 mit einem Backdoor versehen, nachdem er einen Trivy-Scanner in der CI/CD-Pipeline des Projekts kompromittiert und ein PyPI-Token gestohlen hatte. Datadog verbindet die beiden Kampagnen nur über ihr Ziel: Eine Verbindung zwischen den Akteuren ist nicht belegt. Das Muster ist das Unangenehme — ein Gateway, das im Zentrum tausender KI-Stacks sitzt und Provider-Keys sowie Cloud-Credentials hält, hatte binnen acht Monaten zweimal einen korrumpierten Distributionskanal.Die erste Stunde nach dem Runbook
Kodem hat seine Indikatoren mit einem First-Hour-Response-Runbook gepaart, und der Ratgeber von LiteLLM ist genauso unmissverständlich. Der gemeinsame Kern:- litellm 1.107.0 am Package-Proxy blockieren, Floating Tags wie latest nicht mehr deployen und das letzte saubere Release 1.106.2 per Hash pinnen — Images per Digest
- Auf betroffenen Hosts vor der Bereinigung weder python noch pip ausführen, denn jeder Interpreterstart führt die Payload erneut aus
- Hosts und Container isolieren, dann cook.pth, cook.py, sitecustomize.py samt kompilierter .pyc-Dateien von Hand löschen
- Von einer sauberen Maschine aus rotieren: Cloud-Rollen, in der Proxy-Datenbank gespeicherte Provider-Keys, LiteLLM-Master- und Virtual-Keys, das Datenbankpasswort, Registry- und GitHub-Tokens
- Cloud-Audit-Logs auf GetCallerIdentity-Aufrufe und Credential-Nutzung aus unerwarteter Infrastruktur seit 11:39 UTC am 21. Oktober prüfen