LiteLLM erneut vergiftet: Version 1.107.0 stiehlt KI-Schlüssel - News

LiteLLM ist für viele Unternehmen die zentrale Schaltstelle zu den KI-Anbietern. Das Open-Source-Gateway nimmt Anfragen entgegen und leitet sie an OpenAI, Anthropic, Google oder ein eigenes Modell weiter. Genau deshalb liegen dort die Schlüssel zu allen Anbietern an einem Ort. Am 21. Oktober 2026 war die offizielle Version 1.107.0 mit Schadsoftware verseucht. LiteLLM hat den Vorfall noch am selben Tag offengelegt, die Sicherheitsfirma Aikido und The Register haben ihn analysiert.

Was passiert ist

Betroffen sind das Python-Paket litellm==1.107.0 auf PyPI und die Docker-Images mit den Tags v1.107.0, latest, main-latest und main-stable, sowohl auf Docker Hub als auch in der GitHub Container Registry. Wer also einfach „latest“ gezogen hat, war ebenfalls dabei. Laut LiteLLM lag die verseuchte Version auf PyPI von 11:39 bis 13:23 Uhr UTC online, auf Docker Hub von 11:46 bis 14:20 Uhr UTC.

Der offizielle Quellcode auf GitHub war sauber. Gebaut wurden die Pakete aus einem Doppelgänger-Repository namens Berri-AI/litellm, das dem echten BerriAI/litellm zum Verwechseln ähnelt. Nach dem vorläufigen Bericht von LiteLLM kam der Angreifer zuerst in eine interne LiteLLM-Instanz, die offen im Internet erreichbar war. In deren Logs fand er GitHub-Zugangstoken von Entwicklern. Mit drei solchen Konten überging er den Branch-Schutz, gab die Veröffentlichung frei und löschte danach die Protokolle.

Bemerkenswert ist ein Detail aus dem Bericht: LiteLLM hat beobachtet, dass Claude Code in bestimmten Fällen das GitHub-Token eines Nutzers in eine Antwort einbettet. Werden solche Antworten protokolliert, landen die Token im Log. Ob das hier der Weg war, ist noch nicht bestätigt.

Was die Schadsoftware tut

LiteLLM selbst fasst es knapp zusammen:

„This version contained compiled malware which steals credentials and loads remote-code execution tools.“

Nach der Analyse von Aikido sammelt das Programm unter anderem:

KI-Schlüssel: API-Keys für OpenAI, Anthropic und andere Anbieter, dazu die in der LiteLLM-Datenbank gespeicherten Provider-Keys
Cloud-Zugänge: AWS, Azure und Google Cloud, auch über die Metadaten der Instanz
Entwicklerdaten: SSH- und GPG-Schlüssel, Shell-Historie, Zugangsdaten von git, npm und PyPI sowie von Werkzeugen wie Claude Code, Cursor und GitHub Copilot
Infrastruktur: Kubernetes-Token, Docker-Konfiguration, CI/CD-Secrets und alle Umgebungsvariablen
Browser: gespeicherte Passwörter und Verlauf

Die Beute geht verschlüsselt an eine Domain des Angreifers, die nach LiteLLM aussieht. Zusätzlich richtet sich ein Hintergrundprozess ein, der stündlich neuen Python-Code nachlädt und ausführt. Er startet bei jedem Python-Aufruf neu, auch bei einem harmlosen pip install.

Ein sonniger Containerhafen mit bunten Containern, einer davon steht offen und leuchtet innen rot

Kein Einzelfall

LiteLLM wird laut The Register rund 23 Millionen Mal pro Woche heruntergeladen. Es ist nicht das erste Mal, dass das Projekt zum Einfallstor wird, wir haben über einen früheren Angriff auf LiteLLM berichtet. Am selben Tag meldete auch die Hosting-Plattform Railway einen Einbruch: Ein Unbefugter könnte dort auf Umgebungsvariablen der Kunden zugegriffen haben. Railway spricht von einer Serie von Angriffen auf Plattformanbieter, die letztlich auf KI-Inferenzanbieter zielen, und rät allen Kunden, ihre Schlüssel sofort zu tauschen. Einen Zusammenhang mit LiteLLM stellt keine der Quellen her. Das Muster ist aber deutlich: Schlüssel zu KI-Diensten sind zur begehrten Beute geworden.

Kunden der privaten Enterprise-Version von LiteLLM waren nach Angaben des Projekts nicht betroffen.

Was das für Ihr Unternehmen heißt

Sofort prüfen: Läuft irgendwo LiteLLM in Version 1.107.0, als Paket oder Container, auch in CI-Pipelines? Hinweise sind die Dateien cook.pth, cook.py oder sitecustomize.py in den site-packages sowie /tmp/remote_code_loader.lock. Fehlen sie, ist das laut LiteLLM aber noch kein Beweis, dass alles sauber ist.
Neu aufbauen statt reparieren: Betroffene Images und virtuelle Umgebungen komplett neu bauen und auf 1.106.2 oder eine andere feste ältere Version pinnen. In einer befallenen Umgebung nicht zuerst pip starten.
Alles tauschen: Wer die Version mit Internetzugang ausgeführt hat, sollte davon ausgehen, dass die Daten abgeflossen sind. Also Provider-Keys, Master- und Virtual-Keys, Datenbankpasswort, Cloud-Rollen und SSH-Schlüssel erneuern und die Cloud-Logs auf fremde Nutzung prüfen.
Keine wandernden Tags: latest in Produktion heißt, jede neue Version ungeprüft zu übernehmen. Feste Versionen oder Image-Digests verhindern das.
Keine Geheimnisse in Logs: Wer Antworten von KI-Werkzeugen protokolliert, protokolliert womöglich Token mit. Logs sollten maskiert und nicht frei erreichbar sein. Das gilt auch für Agenten mit eigenen API-Schlüsseln.

Fazit

Ein KI-Gateway bündelt alle Zugänge an einer Stelle und ist damit so wertvoll wie ein Generalschlüssel. Wer es einsetzt, sollte es auch so behandeln: feste Versionen, getrennte Schlüssel je Anwendung, Logs ohne Geheimnisse und ein eingeübter Plan, alle Zugänge an einem Nachmittag zu tauschen. Wenn Sie prüfen möchten, wie gut Ihre KI-Infrastruktur dagegen aufgestellt ist, sprechen Sie mich gern an.