Stand: 25. Oktober 2026. Dieser Beitrag beschreibt den öffentlich dokumentierten Stand der Untersuchung. LiteLLM hat die betroffenen Artefakte entfernt; wer sie im fraglichen Zeitraum eingesetzt hat, sollte trotzdem von einer möglichen Kompromittierung ausgehen.
Ich bin über einen aktuellen Lieferkettenvorfall gestolpert, der auch außerhalb großer Unternehmen lehrreich ist: Eine kompromittierte LiteLLM-Version wurde für kurze Zeit über PyPI und Container-Registries verteilt. Das ist kein klassischer Fehler in einer einzelnen Website, sondern ein Beispiel dafür, wie schnell ein vertrauter Update-Weg zum Risiko werden kann.
Was ist passiert?
Am 21. Oktober 2026 wurde litellm==1.107.0 für ungefähr zwei Stunden auf PyPI angeboten. Parallel zeigten mehrere Docker- und GHCR-Tags auf kompromittierte Images. Laut der offiziellen Untersuchung enthielten die Artefakte Dateien, die beim Start von Python ausgeführt werden konnten und unter anderem Zugangsdaten stehlen sollten. Die betroffenen Artefakte wurden inzwischen entfernt beziehungsweise auf geprüfte Quellen zurückgestellt.
Die wichtigsten Zeitfenster und betroffenen Tags sind in der offiziellen LiteLLM-Meldung dokumentiert. Eine unabhängige Einordnung von CERT-In beschreibt ebenfalls die manipulierten Python-Startmechanismen und die betroffenen Veröffentlichungswege.
Wer jetzt handeln sollte
- Wer
litellm==1.107.0installiert oder einen betroffenen Container-Tag im genannten Zeitraum gestartet hat, sollte die Umgebung als potenziell kompromittiert behandeln. - Eine bloße Neuinstallation reicht nicht aus: Zugangsdaten, API-Schlüssel und Tokens, die in der Umgebung erreichbar waren, sollten widerrufen und neu erstellt werden.
- Die LiteLLM-Empfehlung lautet, vorerst eine ausdrücklich festgelegte, geprüfte Version wie
1.106.2zu verwenden und Images nicht nur überlatestzu beziehen. - Bei einer Untersuchung gehören auch Python-Startdateien, Container-Digests, Shell-Historien und ausgehende Verbindungen auf die Prüfliste.
Die Hinweise sind keine Aufforderung, LiteLLM pauschal zu meiden. Sie zeigen eher, warum reproduzierbare Builds, feste Versionen und überprüfte Quellen im Alltag wichtiger sind als ein möglichst bequemes pip install oder ein unpinned Docker-Tag.
Was bedeutet das für meinen Server?
Auf meinem Plesk-Server setze ich LiteLLM und die betroffenen Docker-Images nicht ein. Der Vorfall ist deshalb kein Hinweis auf einen direkten Treffer in meinem aktuellen Hosting-Setup. Ich nehme ihn trotzdem zum Anlass, bei eigenen Updates genauer hinzusehen: Welche Quelle wird verwendet? Ist eine Version fest gepinnt? Und lässt sich später noch nachvollziehen, was tatsächlich installiert war?
Gerade für private Projekte ist das eine realistische Sicherheitsroutine: wenige, bekannte Komponenten einsetzen, unnötige Paketquellen vermeiden und bei einer Warnung zuerst den tatsächlichen Einsatz prüfen. Das spart meist mehr Zeit, als nachträglich eine ganze Umgebung rekonstruieren zu müssen.
