LiteLLM 1.107.0: Betroffenheit anhand von Artefakten prüfen, ohne kompromittiertes Python zu starten

Worum es geht

Stand: 25. Oktober 2026. Die Vorfallsmeldung von LiteLLM benennt die schädliche Version 1.107.0 vom 21. Oktober. Vor der Wiederherstellung diese Meldung und den zugehörigen massgeblichen Ursachenbericht erneut prüfen. Diese Darstellung berücksichtigt die Korrektur der Meldung vom 23. Oktober, 21:50 UTC, den am 23. Oktober veröffentlichten Ursachenbericht und den OSV-Revisionszeitstempel vom 21. Oktober, 22:01:01 UTC.

Die Herstellermeldung nennt folgende Verbreitungszeiträume, jeweils am 21. Oktober in UTC: PyPI-Wheels, 11:39:51–13:23; Docker Hub, 11:46:56–14:20; GHCR, ab 11:46:56 und spätestens um 13:51 nicht mehr verfügbar. Die Container-Tags waren v1.107.0, latest, main-latest und main-stable. Kopien aus Caches können auch später noch ausgeführt werden.

Warum es wichtig ist

OSV MAL-2026-2144 beschreibt den Diebstahl von Zugangsdaten und einen beim Python-Start aktivierten Mechanismus zum Nachladen von Code aus einer entfernten Quelle, ohne dass eine Anwendung LiteLLM importieren muss. Der Eintrag verbindet ältere Vorfallsinformationen mit Erkenntnissen vom Oktober. Für den Umfang der betroffenen Artefakte die Angaben des Herstellers verwenden; der weit gefasste Versionseintrag von OSV bedeutet nicht, dass jede Version schädlich ist.

Die massgebliche Untersuchung ersetzt die ursprüngliche Theorie zu Deployment-Logs: Ein offengelegter, nicht widerrufener Master-Schlüssel ermöglichte den Zugriff auf einen separaten Agentendienst, der das GitHub-Token eines Eigentümers zurückgab. Mit den gestohlenen Identitäten wurde anschliessend der Release-Prozess kompromittiert. Neben dem Austausch des Pakets ist deshalb auch die Wiederherstellung der Repository- und Kontosicherheit wichtig.

So wird es angewendet

• Betroffene Rechner isolieren und Veröffentlichungen aussetzen. Lock-Dateien, Installationsnachweise, Image-Referenzen und CI-Logs sichern. Festhalten, ob ein Artefakt heruntergeladen, installiert oder ausgeführt wurde; ein aktuelles Verzeichnis der Abhängigkeiten kann entfernte Umgebungen nicht rekonstruieren.
• Eine schreibgeschützte Kopie des Dateisystems mit vertrauenswürdigen Werkzeugen untersuchen. Beispielsweise findet find /mnt/evidence -type d -name 'litellm-1.107.0.dist-info' installierte Metadaten, ohne den verdächtigen Interpreter zu starten. cook.pth, cook.py und sitecustomize.py mit den Indikatoren der Sicherheitsmeldung abgleichen. Allgemeine Dateinamen allein belegen keinen schädlichen Inhalt.
• Aus einer vertrauenswürdigen Administrationsumgebung mit docker image inspect IMAGE_ID gesicherte lokale Image-Metadaten untersuchen. Registry-Digests mit der Herstellermeldung abgleichen und dabei die richtige GHCR-Variante berücksichtigen. Ein aktuell gesetzter veränderlicher Tag belegt nicht, welches Image ein früherer Container verwendet hat; fehlen Registry-Digest-Metadaten, sind Deployment- oder Registry-Aufzeichnungen erforderlich.
• In der verdächtigen Umgebung weder pip noch Python ausführen. Die Umgebung aus sauberen Ausgangsbestandteilen neu aufbauen. Für die Wiederherstellung nach diesem Vorfall gibt der Hersteller die Versionsbindung litellm==1.106.2 vor; diese nur in einer frischen Umgebung mit python3 -m pip install 'litellm==1.106.2' umsetzen. Vor der erneuten Anbindung sämtliche Abhängigkeiten und aktuelle Sicherheitsmeldungen prüfen.
• Von einem sauberen Rechner aus alle zugänglichen Zugangsdaten widerrufen und ersetzen: Zugangsdaten für Veröffentlichungen und Repositories, Cloud-Zugänge, Datenbankpasswörter, Anbieterschlüssel und Anwendungsgeheimnisse. Ihre Nutzung seit dem frühesten plausiblen Zeitpunkt der Gefährdung prüfen. Vor Wiederaufnahme des Betriebs die aufgezeichneten Artefakte der Ersatzumgebung mit den für die Wiederherstellung freigegebenen Ausgangsbestandteilen abgleichen.

Stolpersteine

Die Deinstallation eines Pakets macht den Diebstahl von Zugangsdaten nicht rückgängig und belegt nicht, dass alle Mechanismen zur dauerhaften Verankerung entfernt sind. Fehlende temporäre Spuren belegen keine Sicherheit. Die vorgegebene Versionsbindung behandelt diesen Vorfall, nicht jede andere Schwachstelle; sie erneut prüfen und nicht als dauerhafte Sicherheitsgarantie ansehen.