KIungefiltert

· 4 Min. Lesezeit · Read in English

LiteLLM zum zweiten Mal in diesem Jahr kompromittiert: Infostealer in Version 1.107.0

Am 21. Oktober landete ein manipuliertes LiteLLM 1.107.0 auf PyPI und Docker. Es stiehlt Cloud-Logins, Secrets und KI-API-Keys. Sichere Version: 1.106.2. Wer 1.107.0 gestartet hat, muss alles rotieren.

SicherheitKISelfhosting

LiteLLM ist wieder kompromittiert worden. Am 21. Oktober 2026 haben Angreifer über die offizielle Release-Pipeline eine manipulierte Version 1.107.0 auf PyPI, Docker Hub und GHCR veröffentlicht. Darin steckt ein Infostealer mit Fernzugriffsfunktion. Schon im März hatte es LiteLLM erwischt, das hier ist also der zweite Lieferkettenangriff in diesem Jahr.

LiteLLM ist ein weit verbreiteter Open-Source-Proxy, der Anfragen an viele LLM-Anbieter über eine einheitliche Schnittstelle verteilt. Laut BleepingComputer kommt das Paket auf rund 92 Millionen PyPI-Downloads im Monat. Genau deshalb ist es so ein lohnendes Ziel: Auf einem LiteLLM-Host liegen die API-Keys sämtlicher angebundenen KI-Anbieter.

Was passiert ist

Bei einem Lieferkettenangriff (Supply-Chain-Angriff) wird nicht die Software beim Nutzer angegriffen, sondern ihr Verteilungsweg. Hier traf es die Release-Pipeline. Laut dem Vorfallsbericht von LiteLLM waren die Artefakte zu diesen Zeiten verfügbar (UTC, 21. Oktober):

  • PyPI: litellm==1.107.0, sieben Wheels für Linux, macOS und Windows, von 11:39 bis 13:23 Uhr
  • Docker Hub: Tags v1.107.0, latest, main-latest und main-stable, von 11:46 bis 14:20 Uhr
  • GHCR: dieselben Tags für die Images litellm, litellm-database und litellm-non_root, bis 13:51 Uhr

Kunden der privaten Enterprise-Edition waren nicht betroffen. Der offizielle Quellcode-Tag auf GitHub ist sauber, denn gebaut wurde aus einem Lookalike-Repository namens Berri-AI/litellm (das Original heißt BerriAI/litellm). SecurityWeek schätzt anhand von PyPI-Daten über 49.000 Downloads, wobei das nicht dasselbe ist wie 49.000 infizierte Systeme.

Was die Schadsoftware tut

Der Code steckt nicht in LiteLLM selbst, sondern in drei Dateien im site-packages-Verzeichnis (cook.pth, cook.py, sitecustomize.py). Python lädt solche Dateien bei jedem Start des Interpreters. Die Malware läuft also auch dann, wenn LiteLLM gar nicht importiert wird, und sogar dann, wenn man pip aufruft, um nachzusehen.

Abgegriffen werden laut Help Net Security und BleepingComputer unter anderem Zugangsdaten für AWS, Azure, Google Cloud, Kubernetes und Docker, Git-, SSH- und GPG-Schlüssel, .env-Dateien, Shell-Historien, Browser-Logins und Cookies sowie Auth-Dateien von KI-Werkzeugen wie Claude, Codex, Gemini und Cursor. Dazu kommt ein Versuch, die in der LiteLLM-Datenbank gespeicherten Provider-Keys auszulesen. Ein zusätzlicher Loader fragt stündlich eine Quelle auf GitHub nach nachzuladendem Python-Code ab.

Das ist nicht nur ein Versuch geblieben. Wiz beobachtete etwa viereinhalb Stunden nach dem Datenabfluss, wie die Angreifer gestohlene AWS-Zugangsdaten prüften und den Zugriff auf Amazon-Bedrock-Modelle testeten. Das deutet auf LLMjacking hin, also darauf, dass fremde KI-Kontingente auf Kosten der Opfer genutzt werden sollen.

Was sich seit meinem Post geändert hat

Gepostet hatte ich, dass die Angreifer gekaperte GitHub-CLI-OAuth-Tokens benutzt haben. Das stimmt nach wie vor. Woher die Tokens stammen, war in der ersten Version des Vorfallsberichts aber falsch dargestellt. Damals vermutete LiteLLM, die Tokens seien über Logs einer öffentlich erreichbaren internen Instanz abgeflossen. In der korrigierten Ursachenanalyse vom 23. Oktober steht etwas anderes: Im Mai wurde ein administrativer Schlüssel für eine interne Agent-Plattform versehentlich in ein öffentliches Repository committet und danach nie widerrufen. Über diesen Schlüssel kamen die Angreifer am 10. Oktober an das Token eines GitHub-Organisationsinhabers, danach an die Tokens weiterer Maintainer, und am 21. Oktober schließlich an die Release-Pipeline. LiteLLM selbst schreibt, frühere Annahmen hätten sich als „ungenau oder unvollständig“ herausgestellt.

Für uns heißt das: Am Anfang stand kein raffinierter Zero-Day, sondern ein geleakter Key, den monatelang niemand widerrufen hat.

Was du jetzt tun solltest

  • Prüfen, ob LiteLLM 1.107.0 oder eines der genannten Docker-Tags in Projekten, CI-Runnern oder Images steckt. Achtung: Wer latest oder main-stable im Zeitfenster gezogen hat, ist möglicherweise betroffen, ohne es zu ahnen.
  • Nicht zuerst Python oder pip starten in einer verdächtigen Umgebung. Lieber per Dateisuche nach litellm-1.107.0.dist-info, cook.pth und sitecustomize.py schauen. Wenn nichts auftaucht, heißt das laut LiteLLM übrigens noch nicht, dass das System sauber ist.
  • Neu aufsetzen statt reparieren: Betroffene Systeme isolieren, virtuelle Umgebungen und Images von Grund auf neu bauen, auf litellm==1.106.2 oder eine andere Version von vor dem Vorfall pinnen. Ein Update allein reicht nicht.
  • Alles rotieren, was auf dem Host erreichbar war: Cloud-Rollen und Keys, alle Provider-Keys in der LiteLLM-Datenbank, Master- und virtuelle Keys, Datenbank-Passwörter, SSH-Schlüssel, Tokens in Umgebungsvariablen.
  • Logs prüfen: In AWS CloudTrail nach GetCallerIdentity-Aufrufen um den Installationszeitpunkt und nach Nutzung eurer Credentials von außerhalb suchen.

Mein Rat geht aber über diesen Vorfall hinaus. Ein KI-Gateway ist ein Tresor für API-Keys, und so sollte man es auch behandeln: Versionen fest pinnen statt latest, Images per Digest referenzieren, neue Releases ein paar Tage abhängen lassen. Und wer selbst Software veröffentlicht, sollte geleakte Keys sofort widerrufen, auch wenn das Leck harmlos aussieht. Ein CVE gibt es zu diesem Vorfall übrigens bisher nicht, man kann also nicht darauf warten, dass der Schwachstellenscanner anschlägt.

Quellen