LiteLLM Supply-Chain-Angriff: Schlüssel nie widerrufen

Der LiteLLM Supply-Chain-Angriff vom 21. Oktober begann nicht am 21. Oktober. Laut dem eigenen Ursachenbericht von LiteLLM wurde ein Master-Key, der am 27. Mai in ein öffentliches Repository committet wurde, nie widerrufen. Ein Angreifer nutzte ihn am 10. Oktober, um an das GitHub-Konto eines Organisations-Owners zu kommen, und veröffentlichte elf Tage später ein manipuliertes LiteLLM 1.107.0 auf PyPI und in den Container-Registries.

Was ist passiert beim LiteLLM Supply-Chain-Angriff

Das schädliche Paket war am 21. Oktober von 11:39 bis 13:23 UTC auf PyPI verfügbar. Die Docker-Tags v1.107.0, latest, main-latest und main-stable zeigten von 11:46 bis 14:20 UTC auf ein kompromittiertes Image; die GHCR-Tags waren bis 13:51 UTC entfernt. Laut LiteLLM ist der offizielle Quell-Tag v1.107.0 sauber: Die Artefakte wurden aus einem vom Angreifer kontrollierten Repository mit ähnlichem Namen gebaut (Berri-AI statt BerriAI). LiteLLM beschreibt die Nutzlast als kompilierte Schadsoftware, die Zugangsdaten stiehlt und Werkzeuge zur Ausführung von Fremdcode nachlädt. Enterprise-Kunden mit der privaten Registry waren laut LiteLLM nicht betroffen.

Der Ursachenbericht zeichnet den Weg nach. Der geleakte Schlüssel gehörte zu einem internen Alpha-Dienst. Am 10. Oktober las der Angreifer damit die API dieses Dienstes aus, die das GitHub-CLI-Token eines Organisations-Owners zurückgab, weder an ein Servicekonto gebunden noch eingeschränkt. Über kurzlebige Workflows gingen dann CI-Secrets an einen externen Endpunkt, darunter die Tokens zweier Maintainer. Am 21. Oktober richtete der Angreifer den Release-Workflow auf das ähnlich benannte Repository. Ein Merge wurde blockiert, also hob das Owner-Token den Branch-Schutz auf. Ein Maintainer-Token startete den Release, ein weiteres genehmigte ihn, ein drittes löschte die Laufprotokolle. LiteLLM hatte in der Woche vorübergehend erlaubt, dass zwei beliebige Entwickler Releases auslösen und freigeben. Ein externer Forscher meldete die Kompromittierung laut LiteLLM etwa 20 Minuten nach der Veröffentlichung.

Stand 26. Oktober beschreibt LiteLLM den Vorfall als eingedämmt und hat angekündigt, in der Woche ab dem 26. Oktober Prozessverbesserungen zu veröffentlichen.

Warum das wichtig ist

Der LiteLLM Supply-Chain-Angriff zeigt, wie wenig zwei Freigaben für einen Release bedeuten können. Der Angreifer hielt gültige Zugangsdaten für beide, also sahen beide legitim aus. LiteLLMs eigenes Fazit: Dass ein offengelegter Schlüssel nicht rotiert wurde, machte den Rest erst möglich.

Ein KI-Gateway hält außerdem viele Geheimnisse: Provider-Schlüssel in der Proxy-Datenbank, Master- und Virtual-Keys, das Datenbankpasswort. Annahme: Mittelständische Unternehmen im DACH-Raum testen LiteLLM oder ähnliche Gateways zunehmend in Piloten, oft mit einem ungepinnten pip-Befehl. Für NIS2-Pflichten zur Lieferkette und für die DSGVO ist ein Rotationsprotokoll der brauchbare Nachweis: welche Schlüssel wann ersetzt wurden.

Was Sie jetzt tun sollten

1. Betroffenheit prüfen. Führen Sie in jeder Umgebung pip show litellm aus und suchen Sie nach Version 1.107.0. Bei Containern prüfen Sie, ob das Image mit dem Digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e lief. Suchen Sie nach litellm-1.107.0.dist-info, cook.pth und sitecustomize.py. Ein Fund bestätigt die Betroffenheit; kein Fund beweist nicht, dass die Umgebung sauber ist.
2. In der richtigen Reihenfolge bereinigen. Beginnen Sie nicht mit pip install: Jeder Python-Start führt die schädlichen Dateien erneut aus, auch pip. Löschen Sie cook.pth, cook.py, sitecustomize.py und deren Bytecode-Cache in jedem site-packages-Verzeichnis, beenden Sie den Python-Prozess, der /tmp/remote_code_loader.lock hält, und installieren Sie dann gepinnt auf litellm==1.106.2 neu. Besser ist ein kompletter Neuaufbau von Images und Umgebungen.
3. Alles rotieren, was der Host erreichen konnte. Lief 1.107.0 je auf einem Host mit ausgehender Internetverbindung, gehen Sie davon aus, dass Daten abgeflossen sind. Das umfasst die IAM-Rolle der Instanz oder des Tasks, jeden Provider-Schlüssel in der LiteLLM-Proxy-Datenbank, Master- und Virtual-Keys, das DATABASE_URL-Passwort und jedes Geheimnis in der Umgebung eines beliebigen Prozesses auf diesem Host.
4. Logs prüfen. Suchen Sie in CloudTrail nach GetCallerIdentity-Aufrufen der Instanzrolle rund um den Installationszeitpunkt und danach nach einer Nutzung der Rollen-Zugangsdaten von außerhalb Ihrer Infrastruktur.

DIESEC Einschätzung

Landet ein Geheimnis in einem öffentlichen Repository, rotieren Sie es zuerst und bereinigen Sie die Historie danach. Geben Sie Automatisierung ein eigenes, eng gefasstes Servicekonto statt des CLI-Tokens eines Owners, und behandeln Sie eine Release-Freigabe nur so stark wie die Konten, die sie erteilen können.

Nicht sicher, ob ein geleakter Schlüssel oder ein zu weit gefasstes Token noch Ihre Build-Pipeline öffnet? Kontaktieren Sie DIESEC für eine Prüfung von CI/CD und Secrets-Exposition.

Quellen: LiteLLM-Vorfallsmeldung | LiteLLM-Ursachenbericht | The Hacker News
Veröffentlicht: 2026-10-27 | Kategorie: Lieferkettensicherheit | ~4 Min. Lesezeit