LiteLLM malicious package 1.107.0 stahl Zugangsdaten
Das als Version 1.107.0 veröffentlichte LiteLLM malicious package sammelte Zugangsdaten und installierte eine backdoor, die stündlich Python-Code abrufen und ausführen konnte. LiteLLM gab am Mittwoch bekannt, dass Angreifer mehrere voneinander unabhängige Sicherheitskontrollen umgangen und seine release pipeline kompromittiert hatten, also den automatisierten Prozess zum Erstellen und Veröffentlichen von Software.
Das vergiftete Release wurde am 21. Oktober 2026 gegen 4:00 Uhr PST veröffentlicht. Es erschien als LiteLLM v1.107.0 im Python Package Index (PyPI), dem wichtigsten öffentlichen Repository für Python-Software. Docker Hub und GitHub Container Registry (GHCR) erhielten Images mit den Tags v1.107.0, latest, main-latest und main-stable. LiteLLM erklärte, dass Unternehmenskunden, die seine private Image-Registry nutzten, nicht betroffen gewesen seien und die kompromittierte Version innerhalb von drei Stunden entfernt worden sei.
Nutzer gelten als betroffen, wenn sie zwischen 11:39 Uhr und 13:23 Uhr UTC über pip ein nicht gepinntes LiteLLM package installierten oder zwischen 11:46 Uhr und 14:20 Uhr UTC eines der aufgeführten container images abriefen. Bei einer nicht gepinnten Installation kann der package manager eine verfügbare Version auswählen, statt ein bestimmtes Release zu verlangen. Da häufig verwendete Tags wie latest vergiftet waren, könnten Teams den schädlichen Build erhalten haben, ohne ausdrücklich Version 1.107.0 anzufordern.
Der schädliche Code sammelte Secrets, die mit dem Betriebssystem, Browsern, Entwicklungswerkzeugen, Cloud-Diensten und Werkzeugen für künstliche Intelligenz verknüpft waren. Er sendete die gestohlenen Daten in einem HTTP POST request an litellm[.]dev/healthcheck. Außerdem richtete er einen remote access trojan (RAT) ein, also malware, die es einem externen Operator ermöglicht, Code auf dem kompromittierten System auszuführen.
Die Infektion war in das package eingebettet und nicht in den Anwendungscode von LiteLLM. Endor Labs berichtete, dass durch eine einzige Ergänzung der Maturin-Build-Konfiguration die Dateien cook.pth, cook.py und sitecustomize.py im Python-Bibliotheksverzeichnis abgelegt wurden. Python verarbeitet beim Start .pth-Konfigurationsdateien und importiert sitecustomize. Dadurch konnte der payload jedes Mal aktiviert werden, wenn Python in dieser Umgebung startete, selbst wenn die laufende Anwendung LiteLLM nicht verwendete. Die Datei cook.pth importierte cook.py, das sich selbst decodierte und eine Routine namens privcollect startete, um Secrets zu sammeln und zu übertragen.
Unter Linux und macOS versuchte sitecustomize.py außerdem, domain.txt von einem inzwischen entfernten GitHub-Konto unter github[.]com/letters9813 abzurufen. Wenn die Datei eine nutzbare Adresse bereitstellte, lud die malware ein zweites Python-Programm von /codepy herunter und führte es aus. Aikido stellte fest, dass der loader einen Hintergrundprozess startete, /tmp/remote_code_loader.lock verwendete, um doppelte Instanzen zu vermeiden, und raw[.]githubusercontent[.]com/letters9813/pythonclient-test/main/domain[.]txt wiederholt auf den aktuellen Command Server des Angreifers überprüfte. Anschließend forderte er jede Stunde einen neuen payload an und führte ihn aus. Wiz erklärte, die Datei habe nur anfängliche Testwerte enthalten, bevor GitHub sie gegen 13:30 Uhr UTC entfernte. Wiz bezeichnete die gleichzeitige Verwendung von .pth und sitecustomize.py als die erste dokumentierte Kombination dieser beiden Python-Startmethoden in aktiver malware.
Wiz beobachtete später die Verwendung gestohlener AWS-Instance-Role-Zugangsdaten von kompromittierten CI runners, also Systemen, die Software automatisch erstellen und testen, sowie von Kubernetes-Nodes. Die Aktivität begann ungefähr 4,5 Stunden nach der Übertragung der Secrets. Zwischen 16:20 Uhr und 17:01 Uhr UTC überprüften Verbindungen von 168.100.8[.]57 und 165.227.201[.]8 die Zugangsdaten mit sts:GetCallerIdentity und riefen anschließend bedrock:ListFoundationModels und ListModels auf. Wiz erklärte, diese Abfolge entspreche LLMjacking, der unbefugten Nutzung des Cloud-Zugangs einer anderen Organisation, um Dienste für künstliche Intelligenz in Anspruch zu nehmen. In einer kleinen Zahl von Umgebungen listete der Angreifer außerdem AWS-Rollen, Nutzer und Zugangsdaten auf und fragte Konten sowie Einstellungen für Audit Trails ab.
LiteLLM hatte seinen Release-Prozess bereits nach einem separaten Vorfall im März 2026 geändert. Zu diesen Maßnahmen gehörten die Verlagerung von Releases in ein privates Repository, die Unveränderlichkeit von Docker-Release-Tags, damit sie nicht neu zugewiesen werden konnten, und die kryptografische Signierung von Images. Am 19. Oktober erweiterten die Maintainer jedoch vorübergehend die Release-Berechtigungen für zwei interne Entwickler, die täglich Backports von Bugfixes für Kunden veröffentlichen mussten. Der Angreifer hatte drei Sätze von GitHub-Kommandozeilen-Zugangsdaten von Entwicklern erlangt, darunter einen, mit dem GitHub workflows gestartet werden konnten.
Der Untersuchung von LiteLLM zufolge wurde ein Zugangsdaten-Satz eines Owners der GitHub-Organisation verwendet, um Branch Protections zu deaktivieren und schädliche Änderungen in das Projekt zu erzwingen. Anschließend führte der Angreifer den workflow für ein täuschend ähnlich benanntes Repository namens Berri-AI/litellm aus, statt für das legitime Repository BerriAI/litellm. Dadurch durchliefen die kompromittierten packages und Images den Signierungs- und Veröffentlichungsprozess des Projekts.
LiteLLM erklärte, Situationen beobachtet zu haben, in denen Claude Code den GitHub CLI OAuth token eines Nutzers in einem response body ablegte. Ein OAuth token ist ein wiederverwendbarer Zugangsnachweis für ein Konto, mit dem Software entsprechend den vom Nutzer erteilten Berechtigungen handeln kann. Wenn response bodies protokolliert wurden, konnte der token folglich in LiteLLM-Logs erscheinen. Die Maintainer fanden außerdem ein unerwartetes, harmlos wirkendes Nutzerkonto in einem internen LiteLLM-Deployment, das über das öffentliche Internet erreichbar war. Sie vermuten, dass der Angreifer auf dieses System zugriff und GitHub-Zugangsdaten aus dessen Logs wiederherstellte. Wie das Deployment öffentlich erreichbar wurde und wie der Zugriff erfolgte, ist weiterhin unklar. LiteLLM hat angedeutet, dass eine kürzlich gepatchte Schwachstelle beteiligt gewesen sein könnte, doch die Untersuchung der Ursache dauert an.
Die Verwendung einer .pth-Datei ähnelt der beim Angriff im März beobachteten und TeamPCP zugeschriebenen Technik. Socket erklärte jedoch, dass die verfügbaren Belege keinen Zusammenhang nachweisen. Socket wies auf Unterschiede bei den eingebetteten kryptografischen öffentlichen RSA-Schlüsseln, der Implementierung des Datendiebstahls und dem Verhalten der backdoor hin. Auch ist weiterhin nicht bestätigt, ob bei dem Vorfall im März gestohlene Zugangsdaten zur Kompromittierung im Oktober beitrugen.
Organisationen, die LiteLLM 1.107.0 ausgeführt haben, sollten es entfernen, betroffene Hosts von anderen Systemen trennen, nach den drei schädlichen Python-Dateien suchen, die Domain für die Datensammlung blockieren und jede Ausführung von /codepy untersuchen. Alle Zugangsdaten, auf die aus einer betroffenen Umgebung zugegriffen werden konnte, sollten widerrufen und ersetzt werden, einschließlich Cloud-, Entwickler- und in Browsern gespeicherter Secrets. JFrog empfahl, betroffene Systeme neu aufzubauen und das exakte Python wheel zu überprüfen, also die installierbare package-Datei, statt davon auszugehen, dass ein sauberes Source Repository ein sauberes veröffentlichtes Artefakt garantiert. Endor Labs empfahl außerdem, Netzwerkaufzeichnungen zu prüfen und container images anhand ihres digest, eines festen Identifikators für den exakten Image-Inhalt, zu pinnen, statt einen veränderlichen Tag zu verwenden.
Organisationen, die bei der umfassenderen Reaktion ihrer Infrastruktur auf Vorfälle dieser Art Unterstützung benötigen, bietet AEU-I sicherheitsorientierte IT-, Infrastruktur- und Beratungsleistungen.