Zum Inhalt springen

LiteLLM 1.107.0 gekapert: Release verteilte einen Credential-Stealer

Bösartige Wheels von LiteLLM 1.107.0 lagen am 21. Oktober 2026 von 11:39 bis 13:23 UTC auf PyPI und starteten bei jedem Python-Start einen Credential-Stealer.

Von Tech AI Wire Team

3 Min. Lesezeit

XLinkedIn
LiteLLM's incident report page titled Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised, with its authors and a status line.

Die Zahlen

PyPI wheels carried the malware
7
UTC window the wheels were on PyPI
11:39-13:23
the clean version to reinstall
1.106.2

Angreifer haben am 21. Oktober 2026 ein bösartiges LiteLLM 1.107.0 auf PyPI und Docker veröffentlicht, nachdem sie die Release-Pipeline des Projekts übernommen hatten. Jede Maschine, die es installierte, startete bei jedem Python-Start ein Programm, das Zugangsdaten stiehlt. LiteLLM rät betroffenen Teams, von gestohlenen Geheimnissen auszugehen und sie auszutauschen.

LiteLLM ist ein Open-Source-Werkzeug, das zwischen Apps und Anbietern von KI-Modellen sitzt. Sein Proxy-Server speichert die API-Schlüssel der Anbieter, was ihn zu einem lohnenden Ziel macht.

Was veröffentlicht wurde und wie lange

Der Vorfallbericht von LiteLLM listet jedes betroffene Artefakt. Der offizielle Quell-Tag v1.107.0 auf GitHub ist sauber. Das Release wurde aus einem nachgeahmten Repository namens Berri-AI/litellm gebaut, das laut StepSecurity zehn Commits der Angreifer enthielt.

ArtefaktBetroffenZeitraum (UTC, 21. Oktober)
PyPIAlle sieben Wheels von litellm==1.107.0 (macOS, Linux, musl Linux, Windows)11:39 bis 13:23
Docker Hubv1.107.0, latest, main-latest, main-stable11:46 bis 14:20
GitHub Container RegistryDieselben Tags für litellm, litellm-database, litellm-non_root11:46 bis 13:51

Version 1.106.2 ist sauber, ebenso die Release-Kandidaten von 1.107.0, so StepSecurity. LiteLLM zufolge waren Kunden der privaten Enterprise-Version nicht betroffen.

Wie die Schadsoftware arbeitet

Die Malware wartete nicht darauf, dass jemand LiteLLM importiert. Sie fügte zwei Start-Hooks hinzu, cook.pth und sitecustomize.py. Python führt beide bei jedem Start in dieser Umgebung aus, selbst wenn der Befehl nur pip ist.

Die erste Nutzlast ist ein Stealer, der sich „privcollect“ nennt, berichtet StepSecurity. Er sammelt Cloud-Tokens, private Schlüssel, Zugangsdateien von KI-Werkzeugen, Browserdaten und Umgebungsvariablen. Auch gespeicherte Zugangsdaten des LiteLLM-Proxys nimmt er mit. Die Daten werden verschlüsselt und an litellm.dev geschickt, eine am 13. Oktober registrierte Domain.

Die zweite Nutzlast ist ein Loader, der als versteckter Hintergrundprozess läuft. Jede Stunde liest er einen Hostnamen aus einer Datei auf GitHub, lädt Code von diesem Host und führt ihn aus. Das GitHub-Konto hinter dieser Datei wurde gelöscht, doch infizierte Maschinen fragen weiter dieselbe Adresse ab.

Wie die Angreifer hineinkamen

Der Angriff lief über die GitHub-Konten von drei Entwicklern, sagte LiteLLMs Sicherheitsdirektor Oliver Jensen gegenüber The Hacker News. Ein Zugang schaltete den Branch-Schutz ab, ein zweiter genehmigte das Produktions-Release und ein dritter löschte die Workflow-Protokolle.

In seinem Update um 20:30 UTC schreibt LiteLLM, man gehe davon aus, dass der Angreifer GitHub-CLI-Tokens aus Logs entnommen hat. Die Logs gehörten zu einer internen LiteLLM-Instanz, die aus dem Internet erreichbar war. Das Unternehmen merkt an, dass Claude Code das GitHub-CLI-Token eines Nutzers in einen Antworttext aufnehmen kann. Werden diese Texte protokolliert, landet das Token in den Logs. Zuvor hatte Jensen gesagt, der Weg sei noch nicht geklärt.

Am selben Tag startete GitHub eine öffentliche Vorschau ablaufender GitHub-CLI-Tokens. Laut dem GitHub-Changelog wird ein geleaktes Token dann „innerhalb von Stunden unbrauchbar, statt unbegrenzt gültig zu bleiben“.

Was das für Entwickler bedeutet

Wer LiteLLM betreibt, sollte heute prüfen, und zwar in der Reihenfolge, die LiteLLM vorgibt.

  • Nicht mit pip install anfangen. Die Start-Hooks laufen bei jedem Python-Start erneut. Suchen und beenden Sie zuerst den Prozess, der /tmp/remote_code_loader.lock hält.
  • Erst die Hooks entfernen, dann neu installieren. Löschen Sie cook.pth, cook.py und sitecustomize.py aus site-packages. Installieren Sie litellm==1.106.2, oder besser: Bauen Sie die Umgebung oder das Image komplett neu.
  • Von verlorenen Geheimnissen ausgehen. Laut LiteLLM ist davon auszugehen, dass der Diebstahl gelang, wenn 1.107.0 je auf einem Host mit ausgehendem Internetzugang lief. Tauschen Sie die im Proxy gespeicherten Anbieterschlüssel, seine Master- und virtuellen Schlüssel, das Datenbankpasswort und die Cloud-Rolle der Maschine aus.
  • Per Digest festlegen. Tags wie latest zeigten über zwei Stunden lang auf das schädliche Image. Legen Sie Images per Digest und Pakete per Hash fest.
  • Eigene Tokens verkürzen. Aktivieren Sie ablaufende GitHub-CLI-Tokens mit gh auth login --expiring, verfügbar ab gh 2.103.0. Halten Sie Tokens aus protokollierten Anfrage- und Antworttexten heraus.

Es ist das zweite gekaperte Release von LiteLLM in diesem Jahr, nach den Versionen 1.82.7 und 1.82.8 im März. Gespeicherte Anbieterschlüssel waren auch letzte Woche die Beute in Datenleck bei OpenCode Console legt gespeicherte Schlüssel für KI-Anbieter offen.

Quellen

  1. Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised - LiteLLM
  2. LiteLLM Compromised in Supply Chain Attack Delivering Credential Stealer and Backdoor - The Hacker News
  3. litellm 1.107.0 Compromised on PyPI: Backdoored Wheels Drop a Credential Stealer and an Hourly Remote Code Loader - StepSecurity
  4. GitHub CLI: Opt in to expiring, auto-refreshing OAuth tokens - GitHub Changelog
securitypythonllmsupply-chain

Ähnliche Artikel

Chrome's About page showing the browser up to date on version 153, next to the Settings menu.
Dev-Tools

Chrome wechselt auf einen Zwei-Wochen-Rhythmus

Mit Chrome 153 beginnt ein Zwei-Wochen-Zyklus für Meilensteine, vorher vier Wochen. Chrome 149 und 150 haben laut Google allein 1.072 Sicherheitslücken behoben.