LiteLLM 1.107.0: Schadcode lief bei jedem Python-Start der Umgebung

LiteLLM 1.107.0 lag rund zwei Stunden auf PyPI und gut zweieinhalb Stunden in Docker-Tags

Am 21. Oktober 2026 gelangte die Version litellm==1.107.0 über die kompromittierte Release-Pipeline von LiteLLM auf PyPI und in die Container-Registries. Nach Angaben des Projekts enthielt das Paket einen Credential-Stealer und einen Loader für Remote-Code-Werkzeuge. Laut LiteLLM war die Version auf PyPI von 11:39 bis 13:23 UTC verfügbar, also rund zwei Stunden. Die Docker-Tags v1.107.0, latest, main-latest und main-stable waren demnach von 11:46 bis 14:20 UTC kompromittiert. Das Projekt gibt an, das Image v1.107.0 entfernt und die übrigen Tags auf saubere Quellen zurückgesetzt zu haben. Alle früheren Versionen seien sicher. Kunden mit dem privaten Enterprise-Release seien nicht betroffen gewesen.

Die Schadlogik läuft bei jedem Python-Start, auch ohne Import von LiteLLM

Der Angriff sitzt im Packaging, der LiteLLM-Anwendungscode ist unverändert. Laut Endor Labs legt eine zusätzliche Zeile in der Maturin-Build-Konfiguration die Dateien cook.pth, cook.py und sitecustomize.py im Library-Verzeichnis ab. Python wertet .pth-Zeilen und sitecustomize bei jedem Start aus. Damit löst jeder Python-, pip- oder Test-Aufruf in der Umgebung die Payload aus, selbst wenn LiteLLM nie importiert wird.

Die verbreitete Zuspitzung, schon die Installation lasse Geheimnisse abfließen, trifft den Sachverhalt so nicht genau. Ausgelöst wird beim Start des Interpreters. Ob bereits der installierende pip-Prozess auslöst, geht aus dem Material nicht hervor.

Microsoft beschreibt zwei Ausführungspfade: einen Collector über eine .pth-Pfaderweiterung und einen Unix-orientierten Loader, der über die Site-Konfiguration bestehen bleibt. Der Collector zielt auf Zugangsdaten aus Entwicklerwerkzeugen, KI-Anwendungen, Cloud-Umgebungen, Browsern und Infrastruktur. Ein separates Datenbankmodul fragt die Tabellen LiteLLM_CredentialsTable und LiteLLM_ProxyModelTable ab. Microsoft hat die Ausführung unter Windows und macOS beobachtet. Wer eine verdächtige Umgebung prüft, sollte dort weder Python noch pip starten.

Als Ursache nennt LiteLLM einen nie widerrufenen Master-Key, Dritte sehen die Klärung offen

Im Root-Cause-Bericht vom 23. Oktober, den LiteLLM als „canonical source of truth“ bezeichnet, beschreibt das Projekt Folgendes: Am 27. Mai 2026 wurde im öffentlichen Repository LiteLLM-Labs/lite-harness eine Konfigurationsdatei mit dem Master-Key einer Agent-Platform-Instanz committet. Der Commit wurde später überschrieben, der Key aber nie widerrufen. Zudem nutzte die Agent Platform ein GitHub-Token ohne Service-Account und ohne Scope-Beschränkung.

Dritte zeichnen ein anderes Bild. Shattered.io beschreibt die Untersuchung des Angriffsvektors Stand 25. Oktober als offen. PointGuard und Brandefense nennen zusätzlich gestohlene GitHub-CLI-OAuth-Tokens, möglicherweise aus Logs einer internetexponierten Instanz. LiteLLM räumt ein, frühere Status-Updates seien teils falsch oder unvollständig gewesen. Ob beide Darstellungen dieselbe Kette beschreiben, ist nicht belegt.

Unklar bleibt auch die Herkunft des Codes. Laut LiteLLM existiert kein offizielles v1.107.0-Source-Tag. Endor Labs spricht dagegen von einer „source revision“ mit dem Credential-Stealer.

Betreiber sollen laut LiteLLM von erfolgreichem Datenabfluss ausgehen

LiteLLM empfiehlt, bei jedem internetverbundenen Host, der die betroffenen Artefakte ausgeführt hat, von erfolgreichem Datenabfluss auszugehen. Besonders exponiert sind Proxy-Betreiber. Der Proxy speichert Provider-Credentials und Modellkonfiguration in genau den Tabellen, die das Datenbankmodul abfragt. Ein kompromittierter Proxy kann daher alle Provider-Keys preisgeben.

Für LiteLLM ist es der zweite Supply-Chain-Vorfall in diesem Jahr. Am 24. März waren die Versionen 1.82.7 und 1.82.8 rund 40 Minuten auf PyPI, vermutlich über Trivy in der CI/CD-Pipeline. Das Docker-Image war damals laut LiteLLM nicht betroffen.