LiteLLM Supply-Chain-Angriff und was jetzt tun

LiteLLM Supply-Chain-Angriff veröffentlichte am 21. Oktober 2026 die Version 1.107.0 mit Malware auf PyPI und in Docker-Images. LiteLLM ist ein Python-Gateway, das Sprachmodell-Anbieter vereinheitlicht. Das Paket läuft oft nahe an Cloud- und LLM-Schlüsseln.

Wenn Ihr Team diese Version installierte oder offizielle Floating-Tags im falschen Fenster zog, betrifft das Risiko nicht nur das Paket. Der Payload gelangt zusätzlich in die Python-Umgebung und kann bei jedem Interpreter-Start laufen, auch ohne LiteLLM-Import. Deshalb lautet die Priorität Eindämmung, Hook-Bereinigung, Neuaufbau und Rotation erreichbarer Geheimnisse.

Dieser Leitfaden bleibt im Winkel von Abwehr und Entwicklung. So erhalten Sie das Fenster in UTC und einen klaren Perimeter. Anschließend sehen Sie, wie Exposition nachweisbar wird und was zu rotieren ist. Danach fixieren Sie die litellm 1.106.2 sichere Version und trennen, was noch unter Untersuchung steht.

Was passierte und welches UTC-Fenster galt?#

Am 21. Oktober 2026 wurde die Veröffentlichungskette von LiteLLM kompromittiert, und die Version 1.107.0 erschien mit Credential-Stealer sowie Remote-Code-Loader. Das schlechte Artefakt erreichte PyPI und offizielle Images. LiteLLM 1.107.0 bösartig war damit kein Randfall, sondern der veröffentlichte Build dieses Releases.

Welches UTC-Fenster galt auf PyPI und in Docker?#

Laut der offiziellen Incident-Mitteilung, aktualisiert am 21. Oktober 2026 um 20.30 UTC, lag litellm==1.107.0 etwa zwei Stunden live auf PyPI. Das PyPI-Fenster lief von 11.39 UTC bis 13.23 UTC. Die Docker-Hub-Images v1.107.0, latest, main-latest und main-stable zeigten dagegen von 11.46 UTC bis 14.20 UTC auf den kompromittierten Index.

Der im Hinweis genannte Digest für das schlechte Image auf Docker Hub lautet sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. Auf GHCR waren die entsprechenden Tags ab 11.46 UTC kompromittiert und danach bis etwa 13.51 UTC nicht verfügbar. Der Code-Tag v1.107.0 im legitimen Repository trug die schädlichen Dateien nicht. Die Artefakte stammten daher aus einem vom Angreifer kontrollierten Repository.

Warum reichte der saubere Git-Tag nicht?#

Die Analyse der JFrog Security Research bestätigt, dass alle sieben Wheels der 1.107.0 den Payload trugen. Der Source-Tarball enthielt dagegen nicht dieselben drei Startup-Dateien. Wer nur den Git-Tag oder das sdist prüft, kann das Release deshalb als sauber lesen, während die schlechte Wheel trotzdem auf den Host gelangt. The Register beschrieb denselben Tag als Verbreitung von Secret-Stealer-Malware und eines RAT über PyPI sowie Docker-Registries.

In der Praxis sehe ich am häufigsten, dass Teams „zwei Stunden online“ als zu klein für Inventar abtun. In CI mit Cache, bei automatischem Rebuild und beim Pull von latest reicht dieses Fenster jedoch für Runner, Notebook und Proxy. Die brauchbare Uhr ist die UTC-Zeit von Installer und Registry, nicht die Ortszeit des Büros.

Wer ist betroffen im PyPI, Docker und wer pinnt?#

Sie gehören zum Perimeter, wenn Sie litellm==1.107.0 im PyPI-Intervall installierten. Ebenso, wenn Sie im Docker-Intervall ein Image v1.107.0, latest, main-latest oder main-stable ausführten. Wer eine ältere Version pinnt und die 1.107.0 in diesem Fenster nicht zog, bleibt außerhalb des schlechten Artefakts, muss aber Lockfiles, Caches und lokale Images trotzdem prüfen.

Der offizielle Hinweis trennt Open-Source-Nutzer von Enterprise-Kunden im privaten Registry. Im OSS-Fall gelten ungepinntes pip oder Floating-Tags im Fenster als kompromittiert. Im Enterprise-Fall erklärt LiteLLM, das private Registry für embargierte Verteilung sei nicht betroffen. Das gilt nur, wenn die Installation wirklich aus diesem privaten Kanal kam. Andernfalls gelten öffentliches PyPI sowie öffentliche Tags auf Docker Hub oder GHCR mit demselben Risiko.

Wer im Alltag die Version „repariert“, verändert auch die Exposition. Dependabot, Renovate, Base-Images ohne Digest und pip install -U litellm ohne Hash erhöhen die Chance, die 1.107.0 zu treffen. Niemand muss die Nummer sofort bemerken. Die Datadog Security Labs fassen die Oberfläche als PyPI-Paket sowie GHCR- und Docker-Hub-Tags zusammen und erinnern an hohe wöchentliche Downloads, was die Inventar-Dringlichkeit trotz weniger Stunden Exposition erklärt.

Der teuerste Fehler hier ist die Annahme, ohne Docker sei man sicher, oder umgekehrt. LiteLLM PyPI kompromittiert und LiteLLM Docker Supply Chain sind parallele Vektoren desselben Releases. Das Inventar muss deshalb Lockfile, pip-Historie, Image-Digest und UTC-Zeit des Jobs kreuzen.

Wie erkennt man die Installation der schlechten Version?#

Beginnen Sie mit Installationshistorie und Digest, nicht mit dem Bauchgefühl des Teams. Wenn pip show litellm irgendwann im Fenster auf 1.107.0 zeigte, ist die Umgebung als kompromittiert zu behandeln. Dasselbe gilt, wenn der Container den kompromittierten Digest ausführte. Das bleibt gültig, auch wenn das Paket inzwischen vom öffentlichen Index entfernt wurde.

Suchen Sie nach Spuren von litellm-1.107.0.dist-info und nach 1.107.0-Wheels im Cache. Prüfen Sie außerdem Builds, die zwischen 11.39 UTC und 13.23 UTC am 21. Oktober 2026 ungepinnt installierten. In Containern vergleichen Sie den gezogenen Digest mit sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. Eines dieser Signale bestätigt Exposition. Nichts zu finden reinigt die Umgebung jedoch nicht, weil /tmp-Bereinigung, Rebuild und Volume-Rotation Spuren löschen.

Die Socket meldete, ihr Scanner habe die Wheels Minuten nach der Veröffentlichung markiert. Die Image-Provenance zeigte zudem das Lookalike-Repository Berri-AI/litellm statt des legitimen BerriAI/litellm. Das erklärt, warum der „offizielle“ Source-Tag sauber wirken kann, während das installierbare Artefakt es nicht war. Wenn Ihre Pipeline nur den Git-Tag prüft, konnte sie grün bleiben und trotzdem LiteLLM 1.107.0 bösartig ausliefern.

Viele meinen, ein Deinstallieren lösche das Problem, und liegen meist falsch, weil die Hooks in die Wurzel von site-packages wanderten. Die Versionsprüfung muss deshalb mit der Suche nach cook.pth, cook.py und unerwartetem sitecustomize.py einhergehen. Ohne beide Achsen schließen Sie nur die Hälfte des Inventars.

Welche Kompromittierungsindikatoren listen die Quellen?#

Die nützlichsten IoCs mischen heute Startup-Dateien, Artefakte unter /tmp, Exfiltrationsdomain und Image-Digest. Der offizielle Hinweis fordert Suche nach litellm-1.107.0.dist-info, cook.pth und sitecustomize.py. Er empfiehlt außerdem, den Python-Daemon mit /tmp/remote_code_loader.lock zu beenden, bevor irgendein pip in der schmutzigen Umgebung läuft.

JFrog veröffentlicht eine operative Liste in diesem Rahmen. Darunter liegen die Domain www.litellm.dev und der Pfad /healthcheck. Dazu kommen der Dead-Drop raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt, der Marker /tmp/.pc_once_72129118c59f5636c0bb, Artefakte /tmp/.pc_sq_ sowie /tmp/.pc_e_ und der Digest des betroffenen Images. Laut The Register hob der Aikido-Hunter zudem /tmp/.pc_once_* als Zeichen bereits ausgelöster Exfiltration hervor. Das Loader-Lock wiederum deutet auf aktives oder jüngstes C2 hin.

Der Mechanismus steuert die Jagd. cook.pth erzwingt den Import von cook.py beim Python-Start. sitecustomize.py startet den Loader im Hintergrund. Jedes python, pip oder jeder Job im venv kann die Malware deshalb erneut anstoßen. Der falsche erste Reflex in der Incident Response ist, das venv zu öffnen und „nur einmal pip show“ zu laufen. Steigt der schmutzige Interpreter, können Sie den Payload beim Diagnostizieren neu ausführen.

Bevorzugen Sie Shell- und Dateisystem-Tools, die dieses Python nicht starten. Isolieren Sie die Maschine und sichern Sie DNS-, Proxy- und Cloud-Logs vor aggressiver Bereinigung. Fehlt das Lock auf einem Host, beweist das keinen fehlenden LiteLLM Credential-Diebstahl, weil ephemere Container und /tmp-Bereinigung den Beweis leicht entfernen.

LiteLLM Supply-Chain-Angriff verlangt welche Geheimnisrotation?#

Wenn die 1.107.0 auf einem Host mit Internetzugang lief, fordert der offizielle Hinweis, Exfiltration als möglich anzunehmen. Der Einmal-Ausführungsmarker bestätigt den Fall, wenn er existiert. Fehlt der Marker, entlastet das nicht, weil ephemere Container und /tmp-Bereinigung den Beweis entfernen.

Die Mindestliste der offiziellen Mitteilung umfasst die IAM-Rolle der Instanz oder Task. Dazu gehören alle Provider-Keys in der LiteLLM-Proxy-Datenbank, Master Key und Virtual Keys, das Passwort aus DATABASE_URL sowie jedes Geheimnis in Prozessumgebungen dieses Hosts. Anschließend empfiehlt LiteLLM, CloudTrail auf GetCallerIdentity der Rolle zur Installationszeit und auf Nutzung dieses Materials außerhalb Ihrer Infrastruktur zu prüfen. Für den AWS-Ablauf hilft eine geordnete Log-Priorität, ohne Symptom und Ursache zu vermischen.

Die Analysen von Wiz und JFrog erweitern das Inventar über den Proxy hinaus. Sie beschreiben Sammlung von Browser-, AWS-, Azure- und GCP-Credentials, Tokens und Configs von KI-Tools, SSH- und GPG-Keys, CI-Geheimnissen sowie lesbaren Umgebungsvariablen. Wiz spricht von breiten Sammelmodulen für Browser, Cloud und KI-Dienste. Behandeln Sie das als starke Oberflächenhypothese, nicht als Beweis, dass jedes Modul bei Ihnen lief. Die Rotation sollte dennoch alles abdecken, was der Host erreichen konnte, weil ein lebender Schlüssel teurer ist als frühes Rotieren.

Wirkt die Umgebung „nur wie eine Prompt-Sandbox“, ändert sich das Risiko kaum, wenn echte Provider-Keys, Cloud-Tokens oder ein Volume mit ~/.aws vorhanden waren. Rotieren, widerrufen und neu erzeugen. Danach Nutzung auditieren. Dateien löschen ohne Geheimnisrotation lässt die Tür offen für jemanden, der das verschlüsselte Paket bereits erhielt.

Wie pinnt man die Version und prüft Hash oder Signatur?#

Die sichere Version, auf die offizieller Hinweis, JFrog, Endor Labs und The Register konsistent zeigen, ist die 1.106.2. Der korrekte Pin ist jedoch nicht der erste Befehl. Wenn die Umgebung die 1.107.0 bereits ausführte, kann ein frühes pip install im selben Python cook.pth und sitecustomize.py erneut scharf schalten.

Warum nicht mit pip install beginnen?#

Die Endor Labs betonen, dass der Angriff im Packaging liegt und nicht nur im gelesenen Quelltext der sauberen Tag. Der geprüfte Tag allein zeigt die Build-Änderung nicht, weil Wheels und Images aus einem anderen Build-Pfad kamen. Jeder Befehl, der das schmutzige Python startet, kann die Hooks deshalb erneut laden und den Loader wieder scharf schalten. Diagnose und Remediation müssen außerhalb dieses Interpreters beginnen, bevor Sie irgendetwas installieren oder aktualisieren, sonst verfälschen Sie Inventar und Forensik zugleich.

Defensive Reihenfolge für Eindämmung und Pin#

Folgen Sie dieser defensiven Reihenfolge, angepasst an die offizielle Mitteilung und die JFrog-Hinweise:

1. Isolieren Sie Host oder Container und sichern Sie Netz-, DNS-, Endpoint- und Cloud-Logs, bevor nützliche Beweise gelöscht werden.
2. Entfernen Sie cook.pth, cook.py, sitecustomize.py und zugehörige *.pyc in __pycache__ jedes betroffenen site-packages, mit Tools, die das kompromittierte Python nicht starten.
3. Beenden Sie den detached Prozess zu /tmp/remote_code_loader.lock und prüfen Sie Marker /tmp/.pc_once_, /tmp/.pc_sq_ sowie /tmp/.pc_e_*.
4. Bauen Sie venv oder Image von null neu und pinnen Sie litellm==1.106.2, möglichst mit Hash der guten Wheel und unveränderlichem Digest des guten Images.
5. Rotieren Sie erst danach erreichbare Geheimnisse und auditieren Sie deren spätere Nutzung.

Hash- und Signaturprüfung verringert Wiederholung, ersetzt aber keinen Rebuild. Socket zeigte, dass Build-Provenance eine Lookalike-Quelle mit fast legitimer Optik erfassen kann. Ein Versions-Pin ohne Hash-Pin lässt deshalb Raum für getauschte Artefakte beim nächsten Vorfall. Image-Digest, Wheel-Hash und Repository-Herkunft müssen Release-Routine werden, nicht nur Ritual nach dem Schrecken.

Der Shortcut, der Eindämmung am stärksten verzögert, ist „in place fixen“ und mit demselben schmutzigen Volume weiterarbeiten. Rebuild aus verifiziertem Artefakt kostet jetzt Zeit und verhindert später teure Falsch-Negative. Bei Zweifel zwischen Putzen und Neuaufbau gewinnt Neuaufbau bei den meisten Proxies und KI-Runnern.

Unterscheiden sich Open Source und Enterprise hier?#

Ja, und der Unterschied liegt im Verteilungskanal, nicht in magischer Immunität. LiteLLM erklärt, Kunden im privaten Enterprise-Registry seien von diesem öffentlichen Release 1.107.0 nicht betroffen. Wer vom öffentlichen PyPI oder von öffentlichen Docker-Hub- und GHCR-Tags zog, fällt in das OSS-Szenario des Hinweises.

Im Kommuniqué steht ein zusätzlicher Detailpunkt. Das Unternehmen erwähnt ein embargiertes Release im privaten Kanal zu einer Schwachstelle mit geplanter Offenlegung am 27. Oktober 2026. Das ist unabhängig von der Malware der 1.107.0 und darf nicht als „Enterprise ist bereits gegen alles gepatcht“ gelesen werden. Es bedeutet nur, dass das private Registry laut offizieller Quelle nicht der Kanal des trojanisierten Artefakts dieses Vorfalls war.

Datadog hält zudem fest, dass dies der zweite LiteLLM-Supply-Chain-Kompromiss in 2026 sei. Zum Zeitpunkt ihrer Analyse bestand keine etablierte Verbindung zum früheren, von ihrer Forschung mit TeamPCP-Aktivität verknüpften Fall. Ohne neue Primärquelle, die diesem Ereignis vom 21. Oktober 2026 einen benannten Akteur zuweist, sollte der defensive Text von Angreifer und Lookalike-Repository sprechen, gemäß dem Konsens offener Quellen, nicht von einer konkreten Gruppe.

Im Mischbetrieb liegt das praktische Risiko darin, dass das Enterprise-Team glaubt, „wir sind Kunde, also vorbei“, während ein paralleler Job noch von PyPI installiert. Bestätigen Sie das echte Registry jeder Umgebung. Zieht ein Cluster aus beiden Welten, deckt die Freistellung des privaten Kanals den Knoten nicht ab, der aus der öffentlichen Quelle trank.

Wie senkt man Supply-Chain-Risiken bei KI-Abhängigkeiten?#

Nach der Eindämmung liegt der Gewinn darin, den nächsten Artefakttausch für den Angreifer teurer und für Sie sichtbarer zu machen. Exakter Versions-Pin, Hash-Pin in Python, unveränderlicher Image-Digest und Verbot von latest in Produktion sind das Minimum. Darüber hinaus sperren Sie Floating-Tags in der CI von LLM-Gateways und fordern menschliche Review, wenn das Lockfile die Version eines Proxys anhebt, der Schlüssel speichert.

Überwachen Sie Egress zu Lookalike-Domains und zu Dead-Drops auf raw GitHub. In diesem Fall war die von technischen Analysen genannte Exfiltrationsdomain eine markennahe Variation. Behandeln Sie Startup-Hooks in site-packages außerdem als Persistenzfläche. Keine dieser Maßnahmen beseitigt Supply Chain vollständig. Sie verkürzen Fenster, erhöhen Erkennungschancen und verringern den Blast-Radius, wenn ein Release-Token leckt.

Getrennte Umgebungen für Provider-Keys, kurzlebige Secrets und Notebooks ohne breite Rolle bleiben echte Verteidigung, auch mit Paketscanner in der Pipeline. Die Gewohnheit, die reife Teams von eiligen trennt, ist die Ablehnung eines schnellen Rebuilds mit beweglicher Tag nach dem Vorfall. Nutzt die gestrige Korrektur latest, kann die nächste schlechte 1.10x.y durch dieselbe Tür kommen. Artefakt-Disziplin ist mühsam und genau das, was dieser Fall bestrafte.

Was bleibt offen und was sollte man jetzt überwachen?#

Bis zur offiziellen Aktualisierung am 21. Oktober 2026 um 20.30 UTC gab LiteLLM an, die Angriffskette mit hohem Vertrauen identifiziert zu haben, während die Untersuchung weiterlief. Offizieller Bericht und offene Analysen beschreiben Artefakte aus dem Lookalike-Repository Berri-AI/litellm, nicht aus dem sauberen Tag des legitimen Projekts.

In den hier geprüften offenen Quellen gibt es kein klassisches CVE für einen „Code-Bug“ der 1.107.0, weil der Kern ein trojanisiertes Verteilungsartefakt ist. Ebenso fehlt eine konsolidierte öffentliche Attribution an eine benannte Gruppe mit Primärquelle für dieses konkrete Ereignis. Datadog hält ausdrücklich fest, dass die Verbindung zum früheren Fall von 2026 in ihrem Text nicht etabliert war.

Was in den nächsten Stunden und Tagen zu beobachten ist, sind Aktualisierungen des offiziellen Hinweises, neue IoCs, Signale wiederverwendeter spät rotierter Credentials und jede zweite Stufe über den Remote-Code-Kanal. JFrog warnt, dass Effekte später heruntergeladenen Arbitrary Codes nicht auf das Verhalten des eingebauten Stealers begrenzt bleiben. Ein Host, der Stunden mit lebendem Loader lief, verdient deshalb forensisch mehr als „nur Version getauscht“.

Wer auf den Abschlussbericht wartet, bevor Inventar beginnt, kommt oft nach der Validierung gestohlener Schlüssel. Behandeln Sie den Konsens aus offiziellem Hinweis und Labs als Sofortaktion und reservieren Sie Unsicherheiten für die Hypothesentafel der Untersuchung.

Häufig gestellte Fragen zu LiteLLM Supply-Chain-Angriff#

Dieser Abschnitt beantwortet reale Fragen von Teams, die am Tag des Vorfalls LLM-Proxy, CI und Notebooks betreiben. Die Antworten stützen sich auf den LiteLLM-Hinweis vom 21. Oktober 2026 sowie auf offene technische Analysen von JFrog, Datadog, Socket, Wiz, Endor Labs und The Register. Sie ersetzen keine Forensik Ihrer Umgebung, weil Cache, Volume und Pull-Zeit die Einordnung jedes Hosts verändern.

Muss ich Keys rotieren, wenn ich das Image nur testete und den Container schon gelöscht habe?#

Ja, wenn der Container mit dem schlechten Image ausgeführt wurde und Netzausgang oder Secret-Mounts hatte, bleibt Rotation nötig. Das Löschen des Containers entfernt das ephemere Dateisystem, entwertet aber bereits exfiltriertes Material nicht. Der offizielle Hinweis fordert ausdrücklich die Annahme von Exfiltration, wenn die 1.107.0 mit Internet lief. Rotieren Sie Provider-Keys, Umgebungsgeheimnisse und erreichbare Cloud-Credentials und auditieren Sie danach Nutzung außerhalb des legitimen Fensters.

Bedeutet der saubere Git-Tag der 1.107.0, dass ich dem Release vertrauen darf?#

Nein. Offizieller Hinweis und Socket zeigen, dass der legitime Source-Tag die schädlichen Dateien nicht enthielt, während Wheels und Images aus einem Lookalike-Repository gebaut wurden. Vertrauen allein auf Git-Tag oder sdist war genau der blinde Fleck dieses Falls. Für die Installation zählt die Wheel oder der Digest, den die Umgebung wirklich lud, mit geprüftem Hash und Herkunft.

Entfernt ein pip-Uninstall von litellm die Malware schon?#

In vielen Fällen reicht das als erster Schritt nicht und kann gefährlich sein, wenn der Befehl das schmutzige Python startet. Die Dateien cook.pth, cook.py und sitecustomize.py liegen in der Wurzel von site-packages und feuern beim Startup. Die konvergente Empfehlung lautet, diese Hooks ohne den betroffenen Interpreter zu entfernen, den Loader zu beenden, die Umgebung neu aufzubauen und erst dann die gepinnte 1.106.2 zu installieren. Behandeln Sie isoliertes Uninstall als unvollständig, bis Hooks und /tmp-Artefakte fehlen.

Sind Enterprise-Kunden automatisch sicher?#

Nur wenn die Installation aus dem privaten Registry kam, das LiteLLM als nicht betroffen erklärt. Zog eine Enterprise-Umgebung auch öffentliches PyPI oder öffentliche Tags latest, main-stable oder main-latest im Fenster des 21. Oktober 2026, gehört sie zum selben Playbook wie OSS. Die nützliche Frage ist nicht der kommerzielle Vertrag. Es sind die echte URL und der echte Digest des Artefakts in jedem Cluster.

Worin liegt der praktische Unterschied zu einem Code-CVE?#

Hier ist das Kernproblem die Supply Chain des veröffentlichten Artefakts, nicht ein mit CVSS dokumentierter Bug im Code des sauberen Tags. Die Sofortaktionen drehen sich deshalb um Versionsinventar, Digest, Startup-Hooks und Geheimnisrotation. Auch ohne klassisches CVE in den geprüften Quellen kann der operative Impact hoch sein, weil der Payload früh läuft und Cloud- sowie LLM-Credentials auf demselben Host zielt.

Fazit#

Wenn Ihre Umgebung die 1.107.0 im Fenster des 21. Oktober 2026 berührte, schützt die meisten Teams am besten diese Reihenfolge, nämlich isolieren, Hooks entfernen ohne Python neu zu schärfen, mit hash- oder digest-gepinntem litellm==1.106.2 neu bauen, alles erreichbare rotieren und die Schlüsselnutzung auditieren. Auf einen perfekten Bericht zu warten, bevor Inventar beginnt, verlängert nur die Zeit, in der ein lebendes Credential für den nützlich bleibt, der das Paket bereits sammelte.

Die Antwort ändert sich, wenn Sie mit Herkunft und Uhrzeit beweisen, dass Sie die schlechte Wheel nie installierten und die Floating-Tags im Docker-Fenster nie zogen. Dann lohnt härteres Pinning und Monitoring weiterhin, doch forensische Eindämmung steht nicht mehr im Zentrum. Der konkrete erste Schritt jetzt ist eine Liste von Hosts, Runnern und Proxies mit LiteLLM und die Markierung jener, die an diesem Tag zwischen 11.39 UTC und 14.20 UTC pip oder Pull durchliefen.

Dieser Beitrag ist rein informativ und bildend zum LiteLLM-Supply-Chain-Vorfall vom 21. Oktober 2026 und ersetzt weder eine professionelle Sicherheitsbewertung noch Incident Response oder Forensik in Ihrer konkreten Umgebung.