DepescheSicherheit14. August 2026neu

Der größte KI-Lieferkettenangriff lief über ein Werkzeug, das gar nicht das Ziel war: 2.500 Firmen, 434.000 Build-Pipelines

Die Sicherheitsfirma CloudSEK hat am 11. August 2026 die Auswertung eines Lieferkettenangriffs vom März 2026 veröffentlicht, den sie für den bislang größten seiner Art hält. Betroffen sind nach ihrer rekonstruierten Datenlage mehr als 2.500 Unternehmen und rund 434.000 automatisierte Build-Pipelines. Der Weg dorthin ist das Lehrstück: Angegriffen wurde nicht LiteLLM, der weit verbreitete Proxy vor Sprachmodell-APIs – „LiteLLM was never attacked directly“. Kompromittiert war der Schwachstellen-Scanner Trivy, den LiteLLMs Bau-Pipeline ungepinnt aus der Paketverwaltung nachlud. Über ein Automatisierungs-Token, das rotiert, aber nicht vollständig widerrufen worden war, konnten Angreifer rund 20 Tage lang Schadcode über die veröffentlichten Versionsmarken des Scanners schieben; der vergiftete Scanner floss automatisch in den Bau von LiteLLM und erzeugte die Schadversionen 1.82.7 und 1.82.8, die rund 40 Minuten lang auf PyPI standen. Abgeflossen sind SSH-Schlüssel, AWS-, GCP- und Azure-Zugangsdaten, Kubernetes-Token, .env-Dateien, CI/CD-Geheimnisse – und LLM-API-Schlüssel samt Gateway-Konfiguration.

Die Kette, wie CloudSEK sie beschreibt und wir sie an der Quelle nachgefragt haben: Zuerst wurde der Open-Source-Schwachstellen-Scanner Trivy kompromittiert. Das Mittel war „a leaked automation token, rotated but not fully revoked“, das ein Zeitfenster von etwa 20 Tagen offen ließ, in dem die Angreifer Schadcode über die veröffentlichten Versionsmarken des Scanners force-pushen konnten. LiteLLMs Bau-Pipeline installierte diesen Scanner ungepinnt über die Systempaketverwaltung – „the compromised scanner flowed into the build automatically, and that build produced and published the malicious 1.82.7 and 1.82.8 releases to PyPI“. Die beiden Schadversionen standen nach Angabe des Berichts rund 40 Minuten im Python-Paketverzeichnis.

Was der Schadcode tat: Er kam als bösartige `.pth`-Datei – ein Dateityp, der beim Start des Python-Interpreters ausgeführt wird. Die Folge, wörtlich: „A malicious .pth file runs when Python starts, no explicit LiteLLM import is required.“ Es genügte also, dass das Paket installiert war; es musste nicht einmal benutzt werden. Auf jedem kompromittierten CI-Läufer sammelte die Schadsoftware der Gruppe TeamPCP anschließend ein: „SSH keys, AWS, GCP, and Azure credentials, Kubernetes tokens, .env files and CI/CD secrets“ sowie „LLM API keys and gateway configuration“.

Zum Ausmaß nennt CloudSEK zwei Kennzahlen: „2,500+ companies in CloudSEK's reconstructed exposure dataset“ und „434,000 CI/CD pipelines potentially exposed“. Namentlich führt der Bericht unter anderem Amazon AWS, Samsung, Salesforce, Cisco, Siemens, Airbus, Bosch, Volkswagen, Deutsche Bahn, FedEx, Munich Re, Deloitte, Vodafone, Orange, HP, Philips, Epic Games, X Corp und Zscaler auf. Die Grundlage dafür hat sich CloudSEK nach eigener Angabe „through its intelligence sources“ beschafft – der Bericht sagt nicht, dass die Firma die exfiltrierten Rohdaten selbst besitzt.

⚠️ Was wir bewusst nicht behaupten. Erstens das Datenvolumen: In der englischsprachigen Berichterstattung kursiert die Formulierung, es seien „Terabytes“ an Zugangsdaten abgeflossen – auf der von uns geöffneten CloudSEK-Seite steht dazu auf gezielte Nachfrage nichts, und Ars Technica, das die Zahl trägt, ist für unser Abrufwerkzeug gesperrt. Wir übernehmen sie nicht. Zweitens die Downloadzahl der Schadversionen: steht dort ebenfalls nicht. Drittens der Stand der Aufräumarbeiten: Ob die genannten Unternehmen benachrichtigt wurden oder ihre Zugangsdaten rotiert haben, sagt der Bericht nicht – die aufgeführten „Immediate Actions“ sind Empfehlungen, keine Vollzugsmeldung. Und viertens die Einstufung selbst: CloudSEK ist eine Sicherheitsfirma, die unter anderem Überwachung von KI-Infrastruktur verkauft, und die Zahlen sind ihre eigene Rekonstruktion. Wir führen den Bericht deshalb als Tier B, nicht als Primärquelle im engeren Sinn; die deutschsprachige Bestätigung durch heise online, die wir ebenfalls selbst geöffnet haben, nennt dieselben Kernzahlen.

Nicht verwechseln: Der Vorfall hat nichts mit dem PyPI-Schadpaket zu tun, das Anthropics Mythos 5 im April 2026 während einer Sicherheitsevaluierung veröffentlichte und über das wir Ende Juli berichtet haben. Dass in beiden Fällen ein Schadpaket rund eine Stunde im Python-Verzeichnis stand und ein Sicherheits-Scanner eine Rolle spielt, ist eine Ähnlichkeit der Angriffsform, nicht derselbe Vorgang.

// Einordnung der Redaktion

Warum das relevant ist

Für ein Portal über KI ist der Fall aus zwei Gründen mehr als eine Sicherheitsmeldung. Erstens steht am Ende der Beutekette ausdrücklich das, was diese Branche zusammenhält: „LLM API keys and gateway configuration“. Wer einen Modell-Proxy betreibt, hat dort die Schlüssel aller angebundenen Anbieter liegen – ein einziger kompromittierter Build-Lauf greift damit nicht ein Konto ab, sondern das Zugangsbündel zu jedem Modell, das eine Organisation nutzt, mitsamt der Konfiguration, die verrät, wo überall abgerechnet wird. Zweitens ist die Angriffskette genau die Sorte Risiko, die in Sicherheitsdiskussionen über KI systematisch unterschätzt wird: Niemand hat LiteLLM angegriffen. Der Fehler war eine ungepinnte Abhängigkeit im Bauprozess – ein Scanner, ausgerechnet ein Sicherheitswerkzeug, den die Pipeline bei jedem Lauf frisch aus der Paketverwaltung zog. Die Kette lief von einem nicht vollständig widerrufenen Token über ein fremdes Projekt in ein zweites, das mit dem ersten nichts zu tun hatte, und von dort in 434.000 Build-Läufe. Das ist die praktische Widerlegung des Gedankens, man könne die eigene Lieferkette absichern, indem man den eigenen Code absichert. Und es gehört neben unsere bisherige Berichterstattung zu Paket-Halluzinationen und Slopsquatting: Dort ist der Einstieg ein Name, den ein Modell erfindet, hier eine Version, die eine Pipeline nicht festnagelt – dasselbe Loch von zwei Seiten.