LiteLLM 1.107.0 war ein Credential-Stealer

Wer am Mittwoch, dem 21.10.2026, LiteLLM aktualisiert hat, sollte heute nachsehen, welche Version läuft. Zwischen 13:39 und 15:23 Uhr deutscher Zeit lag auf PyPI eine Version 1.107.0, die Zugangsdaten stiehlt und eine Hintertür einrichtet. Bis 16:20 Uhr zeigten auch die Docker-Tags v1.107.0, latest, main-latest und main-stable auf Docker Hub und GHCR auf verseuchte Images. Das berichten das LiteLLM-Team in seinem Incident-Report und die Sicherheitsfirma SafeDep, die den Schadcode zerlegt hat.

LiteLLM ist ein quelloffenes Gateway, das viele Teams selbst betreiben, um OpenAI, Anthropic, Google und lokale Modelle hinter einer Schnittstelle zu bündeln, mit Budgets und Logging. Genau deshalb liegen dort die wertvollsten Schlüssel eines KI-Stacks.

Was der Schadcode tut

SafeDep beschreibt zwei Teile. Eine Datei cook.pth sorgt dafür, dass der Stealer bei jedem Start eines Python-Prozesses auf dem Rechner mitläuft, nicht nur beim Start von LiteLLM. Er sammelt SSH-Schlüssel, Zugangsdaten für AWS, Azure, Google Cloud, Kubernetes und Docker, CI/CD-Secrets, Tokens von KI-Entwicklerwerkzeugen, im Browser gespeicherte Passwörter, Umgebungsvariablen sowie die Provider-Keys aus der Datenbank des LiteLLM-Proxys. Auf Cloud-Instanzen fragt er zusätzlich die Zugangsdaten der Instanzrolle beim Metadatendienst ab. Alles geht verschlüsselt an www.litellm[.]dev, eine Domain, die nach dem Projekt klingt, aber nicht dazugehört.

Der zweite Teil ist eine Hintertür über sitecustomize.py. Ein Hintergrundprozess holt sich stündlich die Adresse eines Servers aus einer Datei auf GitHub, lässt den Stealer erneut laufen und führt Code aus, den er von dort lädt. Das GitHub-Konto ist inzwischen gelöscht, die Hintertür findet also aktuell keinen Server mehr. Wer vorher erreichbar war, kann laut SafeDep aber schon Nachschub bekommen haben.

Wie es passiert ist

Bemerkenswert ist der Weg. Der Angreifer hat kein fremdes Paket hochgeladen und keinen Maintainer-Account auf PyPI übernommen. Laut LiteLLM besaß er GitHub-CLI-Tokens mehrerer Entwickler, vermutlich aus den Logs einer intern genutzten LiteLLM-Instanz, die öffentlich erreichbar war. Das ist noch nicht bestätigt. Mit dem Token eines Organisationsinhabers setzte er sich über den Branch-Schutz hinweg und richtete den Release-Workflow auf ein Repository mit fast gleichem Namen aus, Berri-AI/litellm statt BerriAI/litellm. Die Freigabe holte er sich mit den Zugangsdaten eines zweiten Entwicklers.

Danach erledigte die echte Pipeline den Rest: Sie baute, signierte und veröffentlichte die Pakete. Signatur und Herkunft sahen deshalb korrekt aus. Der Git-Tag v1.107.0 im offiziellen Repository ist laut LiteLLM sauber, ebenso die private Enterprise-Registry.

Für LiteLLM ist es nicht der erste Fall in diesem Jahr. Im Frühjahr war das Projekt schon einmal Ziel eines Supply-Chain-Angriffs, damals über manipulierte Pull Requests, wie wir im Mai im Überblick zu KI-gestützten Angriffen beschrieben haben.

Prüfen, aufräumen, Schlüssel tauschen

Betroffen ist, wer am 21.10.2026 im genannten Zeitfenster litellm==1.107.0 installiert oder eines der genannten Docker-Tags gezogen hat. Unbetroffen sind laut SafeDep 1.106.2 und die Release-Kandidaten 1.107.0rc1 und rc2. Ein Hinweis aus dem Incident-Report vorab: In einer verdächtigen Umgebung nicht als Erstes pip install aufrufen. Jeder Python-Start führt den Schadcode erneut aus.

• Version prüfen. pip show litellm liefert die Version, aber eben über Python. Ohne Python-Start geht es mit einer Suche nach litellm-1.107.0.dist-info, cook.pth und sitecustomize.py in den site-packages. Bei Containern das Image-Digest mit dem im Incident-Report genannten Index sha256:1bbcb144… vergleichen.
• Aufräumen und neu bauen. cook.pth, cook.py, sitecustomize.py und die zugehörigen .pyc-Dateien entfernen, den Hintergrundprozess beenden, der /tmp/remote_code_loader.lock hält. Besser ist, die virtuelle Umgebung oder das Image komplett neu aufzubauen, auf 1.106.2 gepinnt.
• Alle Secrets tauschen, wenn der Rechner Internet hatte. LiteLLM rät, dann von Abfluss auszugehen: die Rolle der Instanz, alle Provider-Keys in der Proxy-Datenbank, Master- und Virtual-Keys, das Datenbankpasswort aus DATABASE_URL und alles, was sonst in der Umgebung des Prozesses stand. Da der Stealer jeden Python-Prozess auf dem Host abgreift, gehören auch SSH-Schlüssel und die Zugänge anderer Werkzeuge auf diesem Rechner dazu.
• Logs ansehen. Verbindungen zu www.litellm.dev und Anfragen aus Python-Prozessen an 169.254.169.254 sind verdächtig. Bei AWS empfiehlt LiteLLM, in CloudTrail nach GetCallerIdentity der Instanzrolle rund um den Installationszeitpunkt zu suchen und nach Nutzung der Rollen-Credentials von außerhalb.

Wer nichts findet, ist damit noch nicht entlastet. Das LiteLLM-Team weist selbst darauf hin, dass Container-Neustarts und aufgeräumte /tmp-Verzeichnisse Spuren verwischen. Im Zweifel lieber einmal zu viel rotieren.

Selbst gehostet heißt selbst gepflegt

Ein selbst gehostetes Gateway ist aus Datenschutzsicht oft die bessere Wahl, als die Anfragen über einen weiteren Dienstleister zu schicken. Daran ändert der Vorfall nichts. Er zeigt aber, dass "selbst gehostet" nur heißt, dass man den Betrieb selbst verantwortet, inklusive der Updates.

Zwei Gewohnheiten hätten hier viel abgefangen. Wer feste Versionen in einem Lockfile mit Hashes pinnt und Images über ihr Digest statt über latest bezieht, bekommt eine neue Version nicht automatisch am Tag ihres Erscheinens. Und wer neue Releases ein paar Tage liegen lässt, bevor sie in Produktion gehen, ist bei einem Angriff wie diesem, der nach knapp zwei Stunden entdeckt war, schlicht nicht dabei. Das gilt für jedes Werkzeug, das Schlüssel verwaltet, nicht nur für LiteLLM. Wie ein Gateway sonst in den Stack passt, steht in unserem Artikel über Modellrouter.

Der Tag war auch sonst kein guter für Plattformen, auf denen KI-Anwendungen laufen. Laut TechCrunch kamen am selben Tag kritische PHP-Lücken und kompromittierte Schlüssel der Zertifizierungsstelle eMudhra dazu. Der Hoster Railway meldete außerdem einen Zugriff auf Umgebungsvariablen von Kunden und ordnet ihn einer Angriffsserie auf Plattformen zu, die KI-Inferenzanbieter bedienen. Zu PHP haben wir eine eigene News.