Die Release-Pipeline von LiteLLM wurde am 21. Oktober 2026 kompromittiert. Ein Angreifer konnte dadurch eine schädliche Version der KI-Gateway-Software über PyPI, Docker Hub und GitHub Container Registry veröffentlichen.
Das betroffene Release LiteLLM v1.107.0 sammelte auf den Systemen, auf denen es lief, Zugangsdaten und andere Geheimnisse ab. Dies geht aus Erkenntnissen von Aikido und Wiz hervor, die The Hacker News wiedergibt. Wiz beobachtete anschließend Versuche, gestohlene AWS-Zugangsdaten von kompromittierten CI-Runnern und Kubernetes-Knoten zu validieren.
LiteLLM machte den Vorfall in einer Warnmeldung am Mittwoch öffentlich. Das Unternehmen gab den Eindringzeitpunkt mit etwa 4:00 Uhr PST am 21. Oktober 2026 an.
Welche Pakete und Container-Tags betroffen waren
Zu den kompromittierten Artefakten gehörten:
- PyPI-Paket LiteLLM v1.107.0
- Docker/GHCR-Tag v1.107.0
- Docker/GHCR-Tag latest
- Docker/GHCR-Tag main-latest
- Docker/GHCR-Tag main-stable
Für PyPI umfasst das gemeldete Expositionsfenster Nutzer, die ein nicht fixiertes LiteLLM-Paket mit pip zwischen 11:39 und 13:23 Uhr UTC installiert haben.
Das Expositionsfenster für Container lief von 11:46 bis 14:20 Uhr UTC für Nutzer, die die aufgeführten Image-Tags abgerufen oder anderweitig verwendet haben. Da mehrere veränderliche Tags betroffen waren, reicht es unter Umständen nicht aus, nur das konfigurierte Tag einer Bereitstellung zu prüfen, um festzustellen, welches Image tatsächlich lief. Verteidiger sollten daher das genaue verwendete Artefakt bzw. Image überprüfen.
Gestohlene GitHub-Tokens ermöglichten ein manipuliertes Release
Laut LiteLLM hatte der Angreifer Zugriff auf drei Sätze von Entwickler-Zugangsdaten für die GitHub CLI. Einer davon konnte GitHub-Workflows auslösen. Ein Token eines Organisationsinhabers wurde genutzt, um den Branch-Schutz zu deaktivieren und schädliche Änderungen per Force-Push einzuspielen.
Der kompromittierte Workflow wurde vom legitimen Repository BerriAI/litellm auf ein täuschend ähnliches Repository namens Berri-AI/litellm umgeleitet. Durch diesen Austausch durchliefen die schädlichen Pakete und Images den Signier- und Veröffentlichungsprozess des Projekts.
Zwei Tage zuvor, am 19. Oktober 2026, hatte LiteLLM die Release-Berechtigungen für zwei interne Ingenieure vorübergehend erweitert. Diese sollten täglich Bugfix-Backports für Kunden bereitstellen.
Das Unternehmen vermutet, dass die GitHub-Tokens über Logs einer aus dem Internet erreichbaren internen Bereitstellung offengelegt worden sein könnten. Dort fand es ein unerwartetes, harmlos benanntes Konto. LiteLLM zufolge kann Claude Code das OAuth-Token der GitHub CLI eines Nutzers in einen Antworttext einfügen. Werden diese Antworttexte protokolliert, kann das Token folglich in den LiteLLM-Logs erscheinen. Das Unternehmen stellte dies als vermuteten Weg dar, nicht als belegten initialen Einstiegspunkt.
Nach einem separaten Vorfall im März 2026 hatte LiteLLM laut eigenen Angaben zusätzliche Schutzmaßnahmen für Releases eingeführt. Dazu gehörten die Verlagerung der Releases in ein privates Repository, die Unveränderbarkeit der Docker-Release-Tags und die Signierung der Container-Images. Beim Angriff im Oktober gelang es dem Angreifer dennoch, den Workflow zu manipulieren, der signierte Artefakte erstellt und veröffentlicht.
Die Schadsoftware sammelte Geheimnisse und hielt eine stündlich abfragende Hintertür aufrecht
Aikido und Wiz beschrieben zwei Python-Ausführungsmechanismen, die in das kompromittierte Release eingebettet waren.
Der erste verwendete cook.pth, das ein Python-Modul namens cook importierte. Das zugehörige Skript cook.py entschleierte sich selbst und startete eine Routine zum Diebstahl von Zugangsdaten namens privcollect.
Der Stealer zielte auf Geheimnisse ab, die mit folgenden Bereichen verbunden sind:
- Betriebssysteme
- Webbrowser
- Entwicklungswerkzeuge
- Cloud-Umgebungen
- KI-Werkzeuge
Gesammelte Informationen wurden per HTTP-POST-Anfrage an folgende Adresse gesendet:
litellm[.]dev/healthcheck
Unter Linux und macOS versuchte eine zweite Komponente namens sitecustomize.py, domain.txt aus einem GitHub-Dead-Drop abzurufen, der mit github[.]com/letters9813 verbunden ist. Eine gültige Antwort lieferte die Adresse, von der die Schadsoftware ein Python-Skript der zweiten Stufe unter <domain>/codepy herunterladen und ausführen konnte.
Die Komponente startete außerdem einen Hintergrundprozess und legte die Sperrdatei /tmp/remote_code_loader.lock an. Danach ging sie in eine Schleife, die den Dead Drop stündlich prüfte, bevor sie erneut versuchte, die entfernte Nutzlast auszuführen. Aikido stufte diesen Mechanismus als Remote-Access-Trojaner ein.
Laut Wiz entfernte GitHub die Textdatei des Dead Drops gegen 13:30 Uhr UTC. Vor der Entfernung soll die Datei nur anfängliche Testwerte enthalten haben.
AWS-Zugangsdaten wurden Stunden nach der Exfiltration getestet
Laut Wiz begann der Missbrauch etwa 4,5 Stunden nach der Exfiltration der Zugangsdaten. Zwischen 16:20 und 17:01 Uhr UTC am 21. Oktober 2026 testete der Angreifer AWS-Instanzrollen-Zugangsdaten, die von CI-Runnern und Kubernetes-Knoten stammten.
Jede Zugangsdatensatz wurde mit folgenden Aufrufen geprüft:
sts:GetCallerIdentitybedrock:ListFoundationModels- einem
ListModels-Aufruf
Wiz stufte diese Aktivität als konsistent mit LLMjacking ein, bei dem gestohlene Cloud-Zugangsdaten auf Zugriff auf gehostete KI-Dienste getestet werden. In einigen wenigen Umgebungen führte der Angreifer zudem IAM- und Infrastruktur-Erkundung durch, etwa mit Operationen wie ListRoles, ListUsers, ListAccessKeys, ListAccounts und DescribeTrails.
Der Datenverkehr zur Überprüfung der Zugangsdaten war folgenden Adressen zugeordnet:
168.100.8[.]57
165.227.201[.]8
Obwohl die Verwendung einer .pth-Datei an den im März 2026 erfolgten Angriff erinnert, den die Berichterstattung TeamPCP zuschreibt, fand Socket keine öffentlichen Belege dafür, dass beide Vorfälle denselben Betreiber hatten. Socket verwies auf Unterschiede bei den eingebetteten RSA-Public-Keys, dem Exfiltrationscode und dem Verhalten der Hintertür. Zudem erklärte Socket, die verfügbaren Belege ließen nicht erkennen, ob im März gestohlene Zugangsdaten zur Kompromittierung im Oktober beigetragen haben.
Was LiteLLM-Nutzer jetzt tun sollten
Organisationen, die LiteLLM 1.107.0 installiert oder ausgeführt haben, auch über die betroffenen Container-Tags, sollten den Host und die Zugangsdaten, auf die dieser Prozess zugreifen konnte, als potenziell kompromittiert behandeln.
Empfohlene Maßnahmen:
- LiteLLM 1.107.0 entfernen auf Rechnern und in Bereitstellungsumgebungen.
- Betroffene Hosts isolieren, während untersucht wird, worauf das Paket zugegriffen hat.
- Suchen nach:
cook.pthcook.pysitecustomize.py/tmp/remote_code_loader.lock
- Verbindungen zu folgenden Zielen blockieren und untersuchen:
litellm[.]dev/healthcheckgithub[.]com/letters9813raw[.]githubusercontent[.]com/letters9813/pythonclient-test/main/domain[.]txt
- Jeden versuchten oder erfolgreichen Aufruf von
/codepyuntersuchen. - AWS-Logs auf Aktivitäten mit den genannten IP-Adressen und API-Aufrufen prüfen.
- Alle Zugangsdaten rotieren, die aus einer betroffenen Umgebung erreichbar waren, einschließlich Geheimnisse für Cloud, Entwicklung, Browser und KI-Dienste.
- Betroffene Systeme aus vertrauenswürdigen Artefakten neu aufsetzen, statt sich nur auf das Entfernen der schädlichen Dateien zu verlassen.
Auch der JFrog-Forscher Guy Korolevski riet Organisationen, das genau installierte Wheel zu bestätigen und Paketversionen zu prüfen, bevor sie in Build-Systeme gelangen. Falls 1.107.0 ausgeführt wurde, empfiehlt JFrog, alle Zugangsdaten zu rotieren, auf die das Paket zugreifen konnte, und die betroffene Umgebung neu aufzusetzen.
