153 GByte aus 40 Minuten: Was der LiteLLM-Angriff über Lieferketten verrät - News

Vierzig Minuten - So lange waren zwei manipulierte Versionen der Software LiteLLM am 24. März 2026 im Python-Paketverzeichnis PyPI verfügbar, bevor der Betreiber sie unter Quarantäne stellte. Wie viel in dieser Dreiviertelstunde abfloss, ist erst jetzt bekannt: Die Sicherheitsfirmen CloudSEK und Hudson Rock haben die Beute ausgewertet, deutsche Medien berichteten ab dem 13. August 2026 darüber. Das Ergebnis ist ein Archiv von 153 GByte mit 433.909 Dateien, zugeordnet zu 2.488 Organisationen.

Wie die Kette riss

Bemerkenswert ist, dass LiteLLM selbst nie das eigentliche Ziel war. Die Angreifergruppe TeamPCP, die Google unter der Bezeichnung UNC6780 führt, hatte zuvor den Schwachstellenscanner Trivy kompromittiert. LiteLLM band diesen Scanner in die eigene Bauumgebung ein, ohne ihn auf eine geprüfte Version festzulegen. Damit lief bei jedem Durchlauf automatisch der manipulierte Scanner mit, der den Veröffentlichungs-Token für PyPI abgriff. Mit diesem Token konnten die Angreifer die Versionen 1.82.7 und 1.82.8 als offizielle Releases veröffentlichen.

Erst Trivy, dann das Build-System, dann das Release: ein nicht widerrufener Token, drei Werkzeuge tief.

So beschreibt CloudSEK den Ablauf. Der Satz ist deshalb lehrreich, weil keine der drei Stationen für sich genommen fahrlässig aussieht. Einen Schwachstellenscanner in die Bauumgebung einzubinden gilt als gute Praxis. Erst die Verkettung macht daraus einen Angriffsweg.

Was der Schadcode einsammelte

Die zweite manipulierte Version war die unangenehmere. Sie brachte eine Datei namens litellm_init.pth mit, die bei jedem Start eines Python-Prozesses ausgeführt wurde, völlig unabhängig davon, ob die Bibliothek im jeweiligen Skript überhaupt aufgerufen wurde. Wer das Paket auf einem Entwicklungsrechner installiert hatte, führte den Schadcode also auch bei völlig unbeteiligten Skripten aus.

Gesucht wurde nach Umgebungsvariablen: API-Schlüssel für Sprachmodelle wie OPENAI_API_KEY und ANTHROPIC_API_KEY, dazu SSH-Schlüssel, Kubernetes-Tokens, Cloud-Zugangsdaten und Datenbankpasswörter. Die Daten gingen verschlüsselt an eine von den Angreifern kontrollierte Domain.

Gestapelte Frachtcontainer in einem Hafenterminal

Wer betroffen ist, und was die Zahlen bedeuten

CloudSEK ordnet die Daten mehr als 2.500 Organisationen und rund 434.000 CI/CD-Pipelines zu. Auf der veröffentlichten Liste stehen unter anderem Volkswagen, Siemens, die Deutsche Bahn, NVIDIA, Cisco, Deloitte, FedEx und die London Stock Exchange Group.

Wichtig ist die Einschränkung, die CloudSEK selbst dazuschreibt: Die Zahlen beschreiben rekonstruierte Exposition. Sie belegen nicht, dass jede genannte Organisation tatsächlich kompromittiert wurde oder dass jeder Zugangsdatensatz gestohlen wurde. Jeder Fall müsse einzeln geprüft werden. Diese Zurückhaltung sollte man mitlesen, wenn Schlagzeilen die Namen großer Konzerne nennen.

Das FBI hatte bereits am 2. Juli eine Warnung unter der Kennung FLASH-20260702-01 veröffentlicht. Kernaussage: Die während der TeamPCP-Kampagne erbeuteten Zugangsdaten dürften noch lange nach dem eigentlichen Vorfall eingesetzt werden. Ein im März gestohlener Schlüssel funktioniert heute, wenn ihn niemand ausgetauscht hat.

Was das für Ihr Unternehmen heißt

Entfernen genügt nicht. Wer die Versionen 1.82.7 oder 1.82.8 im Einsatz hatte, muss alle erreichbaren Zugangsdaten austauschen und die betroffenen Systeme aus einer sauberen Quelle neu aufsetzen. Ein Versionswechsel holt weder gestohlene Schlüssel zurück noch entfernt er hinterlegte Zugänge.
Abhängigkeiten auf Versionen festlegen. Der Einstieg war ein Werkzeug, das ungeprüft in der jeweils neuesten Fassung mitlief. Feste Versionsangaben in Bauumgebung und Paketverwaltung sind unbequem und genau deshalb wirksam.
Tokens brauchen ein Ablaufdatum. Ein Veröffentlichungs-Token ohne Ablauf und ohne enge Rechte ist der Hebel, mit dem sich ein Einbruch in ein anderes Projekt weiterreichen lässt. Prüfen Sie, welche dauerhaft gültigen Zugänge in Ihren Abläufen liegen.
Zugangsdaten gehören nicht in Umgebungsvariablen. Genau dort hat der Schadcode zuerst nachgesehen, weil er sie dort zuverlässig findet. Ein Geheimnisspeicher mit kurzlebigen Freigaben verringert das, was ein einzelner Prozess abgreifen kann.
Fragen Sie Ihre Dienstleister. Wenn Entwicklung oder Betrieb extern liegen, betrifft Sie der Vorfall über deren Bauumgebung. Die Frage lautet nicht, ob Sie LiteLLM nutzen, sondern ob es jemand in Ihrer Kette tat.
Rotation braucht einen festen Ablauf. Fast fünf Monate zwischen Vorfall und belastbarer Zahl sind der Normalfall, nicht die Ausnahme. Wer erst beim Bekanntwerden anfängt zu suchen, hat die Zeit dazwischen verschenkt.

Einordnung für die Praxis

Der Fall ist auch für Betriebe interessant, die LiteLLM nie eingesetzt haben. Die Software ist ein Gateway, das Anwendungen mit verschiedenen Sprachmodellen verbindet, und CloudSEK weist darauf hin, dass genau solche Bausteine zu neuen Knotenpunkten werden: Gateways, Agenten-Laufzeiten, MCP-Server, Vektordatenbanken. An diesen Stellen laufen Zugangsdaten aus dem gesamten Unternehmen zusammen, weil sie ihrem Zweck nach mit allem verbunden sind. Ein Einbruch dort ist deshalb kein lokales Ereignis.

Wer KI-Werkzeuge in die eigene Entwicklung holt, sollte zwei Fragen beantworten können: Welche Zugangsdaten kann dieser Baustein sehen, und wie schnell ließen sie sich austauschen, wenn es ernst wird. Wenn Sie darauf keine klare Antwort haben, ist das die eigentliche Baustelle. Ich unterstütze Sie gern bei der Bestandsaufnahme.