LiteLLM gehackt: Schadcode stiehlt Zugangsdaten über Python und Docker

Ein einziges manipuliertes Python-Paket kann reichen, um die Zugangsdaten eines ganzen Servers offenzulegen. Genau das ist am 21. Oktober 2026 beim weit verbreiteten KI-Werkzeug LiteLLM passiert: Angreifer brachten eine schädliche Version über offizielle Paket- und Containerkanäle in Umlauf. Wer LiteLLM auf einem Linux-Server, einem Entwickler-PC oder in Docker installiert hat, sollte jetzt gezielt prüfen – und vor allem nicht blind mit pip loslegen.

Stand: 25. Oktober 2026. Grundlage sind die Sicherheitsmeldung des Herstellers, sein am 23. Oktober veröffentlichter Abschlussbericht zur Angriffskette sowie Analysen von Microsoft und JFrog.

LiteLLM-Hack 2026: Das Wichtigste in 30 Sekunden

• Betroffen: PyPI-Paket litellm==1.107.0, einschließlich aller sieben veröffentlichten Wheels.

• Außerdem betroffen: offizielle Docker-/GHCR-Images mit v1.107.0 sowie bewegliche Tags latest, main-latest und main-stable im genannten Zeitfenster.

• PyPI-Risikofenster am 21.10.: 13:39 bis 15:23 Uhr deutscher Sommerzeit (11:39–13:23 UTC). Docker Hub: etwa 13:46 bis 16:20 Uhr MESZ.

• Die manipulierten Veröffentlichungen wurden zurückgezogen. LiteLLM empfiehlt als saubere Referenzversion 1.106.2.

• Gefahr: Die eingeschleuste Software konnte Zugangsdaten sammeln und auf Unix-Systemen eine nachladbare Hintertür bereitstellen.

Wichtig: Nur weil eine Software einen KI-Dienst nutzt, ist sie nicht automatisch betroffen. Entscheidend ist, ob die konkrete kompromittierte LiteLLM-Version installiert oder ausgeführt wurde. Auch die gemeldete Zahl von rund 49.000 Downloads beschreibt keine bestätigte Zahl infizierter Rechner.

Was ist LiteLLM und warum betrifft der Angriff so viele?

LiteLLM ist eine Open-Source-Bibliothek und ein Proxy, mit dem Anwendungen verschiedene Sprachmodelle über eine einheitliche Schnittstelle ansprechen können. In einer solchen Umgebung liegen häufig API-Schlüssel, Datenbankverbindungen, Cloud-Berechtigungen und Konfigurationen für KI-Dienste bereit. Genau diese Position macht einen kompromittierten KI-Gateway besonders gefährlich.

Der Angriff ist ein klassischer Supply-Chain-Angriff: Nicht jede einzelne Anwendung wird direkt gehackt. Stattdessen wird eine eigentlich vertrauenswürdige Softwarelieferung manipuliert. Anschließend tragen Administratoren, Entwickler und automatische Build-Systeme den Schadcode selbst in ihre Umgebungen.

So gelangten die Angreifer in die offizielle Release-Pipeline

Der am 23. Oktober veröffentlichte Bericht von LiteLLM rekonstruiert eine ungewöhnliche Kette. Bereits am 27. Mai geriet ein Master-Schlüssel einer experimentellen internen Agent-Plattform in ein öffentliches GitHub-Repository. Die Veröffentlichung wurde korrigiert, aber ausgerechnet der betroffene Schlüssel wurde nicht widerrufen.

Am 10. Oktober benutzte der Angreifer diesen Schlüssel, um auf die Plattform zuzugreifen und darüber einen GitHub-CLI-OAuth-Token mit Organisationsinhaberrechten zu erhalten. Weitere Zugangsdaten von Entwicklern kamen hinzu. Damit konnten Schutzregeln umgangen, ein Freigabeprozess beeinflusst und der Release-Workflow auf ein täuschend ähnliches, vom Angreifer kontrolliertes Repository umgeleitet werden.

Aus dem manipulierten Repository wurden echte, offiziell veröffentlichte Softwareartefakte gebaut und signiert. Wer sich nur den normalen Quellcode oder den GitHub-Tag ansah, konnte die zusätzlichen Schad-Dateien übersehen. Die eigentliche Gefahr steckte in den ausgelieferten Installationspaketen.

Der technische Trick: Schadcode startet mit Python

Microsoft und JFrog fanden in den betroffenen Python-Wheels die Dateien cook.pth, cook.py und sitecustomize.py. Besonders perfide: Python verarbeitet bestimmte .pth-Dateien und sitecustomize.py beim normalen Start. Eine Anwendung musste LiteLLM dafür nicht einmal importieren. Unter Umständen genügte der nächste beliebige Python-Aufruf in derselben Umgebung.

Der eingeschleuste Code versuchte unter anderem, SSH-Schlüssel, Cloud-Tokens, Umgebungsvariablen, Git-Zugangsdaten, Browserdaten und Informationen aus dem LiteLLM-Proxy auszulesen. Daten sollten verschlüsselt an einen vom Angreifer kontrollierten Endpunkt übertragen werden. Für Unix-Systeme war außerdem ein Mechanismus vorgesehen, über den später zusätzlicher Python-Code nachgeladen werden konnte. Dass diese zweite Stufe tatsächlich ausgeführt wurde, konnte Microsoft bei seiner Untersuchung nicht bestätigen.

Bin ich betroffen? Erst prüfen, dann handeln

Wenn du LiteLLM gar nicht verwendest und es auch nicht als Abhängigkeit einer anderen Python-Anwendung oder in einem Container vorhanden ist, spricht derzeit nichts für eine Betroffenheit durch genau diesen Vorfall. Nutzt du LiteLLM, schaue zuerst in Deployment-Protokolle, Image-Digests, Installationshistorie und Lock-Dateien.

ACHTUNG: Führe auf einer möglicherweise infizierten Python-Umgebung zunächst weder python noch pip aus. Auch ein harmlos wirkendes pip show kann den automatischen Startmechanismus erneut auslösen. Untersuche im Zweifel offline, aus einer vertrauenswürdigen Rettungsumgebung oder mit Administratorwerkzeugen, die nicht den verdächtigen Python-Interpreter starten.

Schritt 1: Docker-Container und Images kontrollieren

Auf einem vertrauenswürdigen Docker-Host kannst du die bekannten Container und Image-Referenzen auflisten. Die Befehle untersuchen Docker-Metadaten, ohne Python im möglicherweise betroffenen Container zu starten:

docker ps -a --format '{{.Names}} | {{.Image}} | {{.Status}}'
docker images --digests --format '{{.Repository}}:{{.Tag}} | {{.Digest}}'

Suche nach litellm, ghcr.io/berriai/litellm oder litellm/litellm. Vorsicht bei latest, main-latest und main-stable: Sie können inzwischen wieder auf saubere Images zeigen. Der heutige Tagname allein beweist deshalb nicht, welches Image am 21. Oktober tatsächlich gelaufen ist. Ziehe alte Digests, Deployments, Registrierungsprotokolle und Monitoringdaten hinzu.

Der von LiteLLM dokumentierte kompromittierte Docker-Hub-Index hatte den Digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. Vergleiche ihn mit den damals verwendeten Image-Daten – und beachte, dass in GHCR weitere betroffene Varianten existierten.

Schritt 2: Python-Umgebung ohne Python untersuchen

Unter Linux kannst du von einer sauberen Shell aus nach den Installationsartefakten suchen. Passe den Zielpfad an den tatsächlich gemounteten oder gesicherten Datenträger an. Der folgende Befehl startet selbst keinen Python-Prozess:

sudo find /pfad/zur/geprueften-umgebung -type f -name 'cook.pth' -print
sudo find /pfad/zur/geprueften-umgebung -type f -name 'cook.py' -print
sudo find /pfad/zur/geprueften-umgebung -type f -name 'sitecustomize.py' -print

Wichtig: sitecustomize.py kann auch legitim vorkommen. Ein einzelner Dateiname ist deshalb kein ausreichender Infektionsbeweis. Bewerte Fundort, Dateiinhalt und den Zusammenhang mit litellm-1.107.0.dist-info. Umgekehrt bedeutet ein fehlender Treffer nicht, dass niemals Daten abgeflossen sind – temporäre Dateien und Container können längst gelöscht worden sein.

Schritt 3: Was tun, wenn Version 1.107.0 lief?

• Verdächtige Systeme oder Container isolieren, Automatisierungen stoppen und keine weiteren Python-Prozesse aus der Umgebung starten.

• Protokolle und erreichbare Artefakte sichern. Bei produktiven Systemen den Vorfall als mögliches Eindringen behandeln, nicht als gewöhnliches Softwareupdate.

• Virtuelle Umgebungen und Container aus einer vertrauenswürdigen Quelle vollständig neu aufbauen; die kompromittierte Umgebung nicht weiterverwenden. Für die Bereinigung vorhandener Systeme verweist LiteLLM ausdrücklich auf cook.pth, cook.py, sitecustomize.py und einen möglicherweise aktiven Hintergrundprozess.

• Eine eindeutig vertrauenswürdige LiteLLM-Version installieren, nach Herstellerstand zunächst 1.106.2 oder eine ältere explizit geprüfte Version. Version und Image möglichst per Digest oder Lock-Datei festschreiben.

• Alle potenziell erreichbaren Zugangsdaten außerhalb des kompromittierten Systems erneuern: LLM-Provider-Schlüssel, LiteLLM-Master- und Virtual-Keys, Datenbankpasswörter, SSH- und Cloud-Zugangsdaten, CI-Tokens und eingebundene Secrets.

• Cloud-Audit-Logs, Provider-Abrechnungen, API-Nutzung und ungewöhnliche Login- beziehungsweise Netzwerkaktivitäten rückblickend prüfen.

Ein normales pip uninstall oder ein Container-Neustart reicht nicht aus, wenn der Schadcode bereits Zugangsdaten exportiert hat. Die Rotation der Geheimnisse ist der entscheidende zweite Teil der Wiederherstellung. Speziell bei produktiven Linux- oder Proxmox-Umgebungen gilt: Vor dem Neuaufbau Backup und Beweissicherung planen; ein Snapshot ist kein Ersatz für neue Zugangsdaten.

So schützt du deinen Python- und Docker-Stack künftig

Die wirksamsten Maßnahmen sind unspektakulär, aber wichtig: feste Abhängigkeitsversionen statt blindem Latest-Update, reproduzierbare Builds, Prüfung der tatsächlich gelieferten Pakete, minimale Rechte für CI-Tokens und kurze Gültigkeitszeiten für Geheimnisse. Interne KI-Gateways sollten nicht unnötig öffentlich erreichbar sein. Wird ein Schlüssel versehentlich veröffentlicht, ist eine spätere Löschung aus Git nicht genug – er muss aktiv widerrufen werden.

Für Container gilt zusätzlich: Nutze ein eigenes, möglichst rechteloses Dienstkonto, schränke erreichbare Netzwerkziele ein, lagere Geheimnisse nicht ungeschützt in Images und protokolliere, welcher Image-Digest tatsächlich im Betrieb war. Kein einzelner Schutz ist perfekt. Mehrere unabhängige Kontrollen erschweren aber die gesamte Angriffskette.

Was unterscheidet diesen Angriff von KI-Agenten-Hacks?

Hier hat nicht eine KI selbst beschlossen, Systeme anzugreifen. Der bestätigte Vorfall betrifft einen menschlich gesteuerten Angriff auf Zugangsdaten und eine Software-Lieferkette. KI spielt deshalb eine Rolle, weil LiteLLM als Bindeglied zu KI-Modellen besonders wertvolle Berechtigungen hält.

Auf Luftpoet habe ich bereits erklärt, wie ein anderer Vorfall mit autonomen Systemen verlief: KI-Agenten und der Hugging-Face-Hack 2026. Beide Fälle zeigen unterschiedliche Schwachstellen moderner KI-Infrastruktur.

Wenn du generell Webserver absicherst, findest du auch die aktuellen Anleitungen zum Node.js-Sicherheitsupdate Oktober 2026 und zu den

PHP-Sicherheitslücken 2026. Dort geht es jeweils um andere Risiken – nicht um denselben LiteLLM-Angriff.

Fazit: Der gefälschte Release war echt veröffentlicht

Das Beunruhigende am LiteLLM-Fall ist nicht nur der Schadcode. Die manipulierte Version kam über offizielle Kanäle, trug sich durch vertraute Installationsabläufe weiter und konnte schon bei einem gewöhnlichen Python-Start aktiv werden. Für betroffene Admins heißt das: nicht auf eine harmlose Fehlermeldung warten, sondern Versionshistorie sichern, Systeme vertrauenswürdig neu aufbauen und Zugangsdaten konsequent erneuern.

Der akute Veröffentlichungsvorfall wurde eingedämmt. Ob eine konkrete Umgebung tatsächlich kompromittiert wurde, lässt sich dagegen nur aus deren Installation, Laufzeit und Protokollen beurteilen. Dieser Artikel wird bei belastbaren neuen Erkenntnissen aktualisiert.

Quellen und Aktualität

Offizielle Erstmeldung: LiteLLM – Sicherheitsvorfall vom 21. Oktober 2026 (Herstellerquelle).

Maßgeblicher Abschlussbericht: LiteLLM – Rekonstruktion der Angriffskette vom 23. Oktober.

Technische Analyse: Microsoft Security Research – Python-Startup-Hooks und Credential Theft.

Technische Gegenprüfung: JFrog Security Research – manipulierte Python-Wheels.

Neugierig auf mehr?

Sicherheitslücken, Linux, Docker und KI interessieren dich? Auf Luftpoet findest du verständliche Technikbeiträge mit konkreten Lösungswegen – ohne unnötiges Fachchinesisch.

Weiterlesen: KI-Agenten hacken Hugging Face – Hintergründe zum Cyber-Vorfall.

Ebenfalls aktuell: Node.js Sicherheitsupdate Oktober 2026: So prüfst du deinen Server.

Wenn dir dieser Beitrag gefallen hat, dann schau gerne öfter auf luftpoet.de vorbei. Hier findest du regelmäßig neue Artikel, persönliche Erfahrungsberichte und spannende Einblicke rund um Technik, KI, Gaming und den digitalen Lifestyle. Egal ob Linux, Server oder Smart Home – im Blogbereich warten viele weitere Beiträge darauf, entdeckt zu werden. Vielleicht interessieren dich auch meine aktuellen Projekte, Tipps und Empfehlungen auf der Startseite. 👉 Viel Spaß beim Stöbern – und bis zum nächsten Beitrag auf Luftpoet!