Hacker haben die Release-Pipeline von LiteLLM übernommen und Version 1.107.0 mit Malware verteilt. Die Schadsoftware stiehlt Cloud-Logins, Entwickler-Geheimnisse und API-Schlüssel. Betroffene müssen alle Zugangsdaten tauschen und auf Version 1.106.2 zurückgehen. Der Artikel zeigt, welche Tags betroffen sind und was Teams jetzt prüfen sollten.
Die manipulierte LiteLLM-Version 1.107.0 war am 21. Oktober 2026 knapp zwei Stunden auf PyPI. Wer sie installiert hat, muss sämtliche Zugangsdaten erneuern.
Das Wichtigste in Kürze
- Betroffen ist nur Version 1.107.0. Frühere Versionen gelten als sicher, die letzte saubere Version ist 1.106.2.
- Die Malware sammelt Zugangsdaten. Sie zielt auf Cloud-Logins, Entwickler-Geheimnisse und API-Schlüssel für KI-Dienste.
- Ein Update genügt nicht. Wer die Version geladen hat, soll alle Schlüssel als kompromittiert behandeln und tauschen.
- Es ist der zweite Angriff dieses Jahres. Schon im März wurde LiteLLM Ziel eines Supply-Chain-Angriffs.
Was am 21. Oktober bei LiteLLM geschah
LiteLLM meldet, dass seine Release-Pipeline am 21. Oktober 2026 um 4:00 Uhr PST kompromittiert wurde. Danach landete Version 1.107.0 in der Docker-Registry und auf PyPI. Sie enthielt kompilierte Malware. Diese stiehlt Zugangsdaten und lädt Werkzeuge für Fernzugriff nach. Die betroffenen Releases hat LiteLLM inzwischen zurückgezogen.
Die Hauptquelle ist der Bericht von Help Net Security. Er erschien am 22. Oktober 2026. LiteLLM veröffentlichte seine eigene Meldung am 21. Oktober 2026. Eine spätere Aktualisierung ist nicht belegt. Der Stand der Berichte ist damit der 22. Oktober 2026.
| Kennzahl | Wert | Bedeutung |
|---|---|---|
| Schadversion | 1.107.0 | Nur dieser Release trägt die Malware. |
| Zeit auf PyPI | 11:39 bis 13:23 UTC | Wer in diesem Fenster installierte, ist gefährdet. |
| Docker-Tags | v1.107.0, latest, main-latest, main-stable | Diese Tags lieferten von 11:46 bis 14:20 UTC den bösen Build. |
| Sichere Version | 1.106.2 | Auf diesen Stand sollten Betroffene zurück. |
| Downloads | rund 23 Millionen pro Woche | So gross ist die mögliche Reichweite. |
Laut Socket erreichte das vergiftete Release PyPI in sieben Builds für macOS, Linux und Windows. Eine infizierte Installation kann neben API-Schlüsseln der Anbieter auch Cloud-Identitäten und Datenbank-Verbindungen erreichen.
So kam der Angreifer an die Freigabe
Laut LiteLLM nutzte der Angreifer die GitHub-Konten von drei Entwicklern. Wahrscheinlich dienten gestohlene OAuth-Token der GitHub-CLI. Jedes Konto hatte eine Aufgabe:
- Das erste änderte die Pipeline und löste den Release aus.
- Das zweite gab den Release frei.
- Das dritte löschte die Workflow-Protokolle.
Dadurch blieben den Ermittlern weniger Logs. In einer internen LiteLLM-Instanz fand die Firma ein unauffällig benanntes Konto. Die Instanz war aus dem Internet erreichbar. Die Token wurden vermutlich aus den Logs dieser Instanz gezogen.
Wie der Angreifer in die Instanz kam, ist unbestätigt. LiteLLM vermutet eine kürzlich geschlossene Schwachstelle. Zudem beobachtete die Firma Fälle, in denen Claude Code ein GitHub-CLI-Token in eine Antwort einbettet. Werden Antworten protokolliert, können solche Token in LiteLLM-Logs stehen.
LiteLLM nennt den Vorfall eingedämmt. Die Untersuchung läuft weiter. Die Firma will alle Token ihrer Organisation widerrufen oder erneuern. Kunden von Enterprise mit privater Registry waren nicht betroffen.
Welche Zugangsdaten Betroffene jetzt prüfen und tauschen
Sicherheitsforscher von Aikido raten klar: Wer 1.107.0 vor dem Rückzug installiert hat, soll Zugangsdaten als kompromittiert ansehen. Die Analyse von Wiz nennt 1.106.2 als letzte sichere Version.
Daher lohnt sich ein Blick auf folgende Punkte:
- Prüfe in Lockfiles, Images und Build-Logs, ob 1.107.0 oder einer der vier Docker-Tags im genannten Zeitfenster geladen wurde.
- Tausche Cloud-Zugänge, API-Schlüssel für KI-Dienste, Datenbank-Passwörter und GitHub-Token.
- Setze Versionen auf 1.106.2 fest, bis LiteLLM die Untersuchung abschliesst.
- Kontrolliere, ob Antworten mit Token in Logs landen.
Dabei zählt die Reihenfolge. Zuerst Schlüssel erneuern, danach die Umgebung neu aufbauen. Sonst nutzt der Angreifer die alten Zugänge weiter.
Ein Muster, kein Einzelfall
Im August analysierte Hudson Rock ein Archiv von 153 GB aus dem früheren LiteLLM-Angriff im März. Es liess sich sehr vielen Firmendomains zuordnen, darunter AWS, Samsung, Cisco und Salesforce. CloudSEK nannte eine ähnlich hohe Zahl betroffener Organisationen. Forscher Kevin Beaumont kommentierte den neuen Vorfall mit den Worten, LiteLLM sei schon wieder kompromittiert worden.
Einordnung: Was das für Admins und Entwicklerteams in der Schweiz heisst
Teams, die LiteLLM als KI-Gateway betreiben, sollten heute prüfen, ob sie 1.107.0 gezogen haben. Das Zeitfenster war kurz, die Reichweite wegen der Downloadzahl gross. Wer betroffen war, muss Schlüssel sofort tauschen. Das kostet Arbeitszeit, spart aber den Schaden durch gestohlene Cloud- und Datenbankzugänge. Auch Teams ohne Treffer sollten Versionen festschreiben und Logs mit Token prüfen.
Fazit
Du weisst jetzt, welche Version, welche Tags und welches Zeitfenster betroffen sind. Prüfe heute deine Builds und Container auf 1.107.0. Tausche bei einem Treffer alle Zugangsdaten und gehe auf 1.106.2 zurück. Verfolge danach die Updates von LiteLLM zur laufenden Untersuchung.
Quellen: Help Net Security. Foto: jenniferfgallagher / Pixabay. Stand: 22. Oktober 2026.
Recherche und Entwurf KI-gestützt, geprüft und freigegeben von Andreas Brauckmann · So arbeitet die Redaktion
Änderungshistorie
- — Artikel veröffentlicht.