CloudSEK verbindet den LiteLLM-Supply-Chain-Breach im März mit 2.500 Organisationen

Das Threat-Intelligence-Unternehmen CloudSEK teilte in einem am 11. August 2026 veröffentlichten Bericht mit, dass es mehr als 2.500 Organisationen identifiziert hat, die möglicherweise durch den Supply-Chain-Kompromiss von LiteLLM im März 2026 betroffen sind, einem Open-Source-Gateway, das Entwickler verwenden, um Anfragen an KI-Modelle zu routen, und rekonstruierte ungefähr 434.000 CI/CD-Pipelines, die von der Exposition betroffen waren.

Die Zahlen stammen aus einem CloudSEK-Forschungsbericht, der auf einem Opferdatensatz basiert, den das Unternehmen angibt, seine Threat-Intelligence-Abteilung während der März-Kampagne erlangt hat. CloudSEKs Datensatz enthält hochconfidente Übereinstimmungen, die mit Unternehmensdomänen, Repositories, Anmeldeinformationen oder Infrastrukturen von Organisationen wie NVIDIA, Samsung Electronics, Cisco Systems, Siemens, S&P Global, ServiceNow, Deloitte, Vodafone, X Corp, Zscaler, FedEx, Volkswagen, Thales und London Stock Exchange Group verknüpft sind. Das Unternehmen betont ausdrücklich, was diese Übereinstimmungen bedeuten: Eine hohe Konfidenz beschreibt die Stärke der Beweise, die die exponierten Informationen mit einer Organisation verbinden, nicht den Beweis, dass die Organisation angegriffen wurde oder dass ein Angreifer die gestohlenen Informationen verwendet hat.

Das Ereignis im Mittelpunkt der Forschung begann am 24. März 2026, als eine Gruppe, die als TeamPCP verfolgt wird, schädliche LiteLLM-Versionen 1.82.7 und 1.82.8 im Python Package Index veröffentlichte. Die zurückgeführten Versionen waren etwa 40 Minuten lang verfügbar, bevor sie entfernt wurden. Dieses Zeitfenster war ausreichend: CI/CD-Pipelines installieren Abhängigkeiten automatisch und laufen oft mit umfassenden Berechtigungen, sodass ein vergiftetes Paket durch Unternehmensbuild-Systeme mit Maschinengeschwindigkeit ohne Überprüfung durch einen Entwickler verbreitet wird.

Wie ein ausgetauschtes Token 434.000 Pipelines erreichte

LiteLLM wurde nie direkt angegriffen. Die Kette, die in CloudSEKs Bericht dokumentiert ist, beginnt einen Schritt weiter oben, mit Trivy, einem weit verbreiteten Open-Source-Sicherheitsscanner. Ein ausgetauschtes Automatisierungstoken, das mit dem Scanner verknüpft war, wurde rotiert, aber nicht vollständig widerrufen, was ein Zeitfenster von etwa 20 Tagen ermöglichte, in dem die Angreifer schädlichen Code über die veröffentlichten Versionstags des Scanners pushen konnten. Da LiteLLMs eigene Build-Pipeline Trivy unverankert aus dem Systempaket-Manager installierte, floss der kompromittierte Scanner direkt in die Build-Pipeline ein und die vergiftete Build-Pipeline produzierte und veröffentlichte die schädlichen Versionen 1.82.7 und 1.82.8 im PyPI. Ein nicht widerrufenes Token, drei Tools tief.

Das Payload-Design machte das kurze Zeitfenster zählbar. Version 1.82.8 legte eine schädliche .pth-Datei im Python-Umgebung ab, und .pth-Dateien werden ausgeführt, wenn der Python-Interpreter startet, unabhängig davon, ob LiteLLM jemals importiert wird. Das umgeht Installationszeit-Skript-Schutzmechanismen vollständig. Auf kompromittierten Runnern eskalierte der Credential-Stealer, den das FBI SANDCLOCK nennt, zu Root und sammelte SSH-Schlüssel, AWS-, Google-Cloud- und Azure-Anmeldeinformationen, Kubernetes-Service-Account-Tokens, Umgebungsdateien und CI/CD-Geheimnisse, indem es Werte aus dem Prozessspeicher sammelte, die normalerweise von Tooling maskiert werden. Cloud-Schlüssel kamen direkt aus dem Instanz-Metadatendienst, indem sie den Zugriff nutzten, den der Runner bereits hatte, anstatt eines Exploits. Für AI-Builds insbesondere umfasste die Beute LLM-API-Schlüssel und Gateway-Konfiguration: die Anmeldeinformationen für den gesamten AI-Stack einer Organisation.

Die gestohlenen Daten wurden unter einem hartcodierten Schlüssel verschlüsselt und in eine typosquatted-Domäne exfiltrated. Wo die Exfiltration fehlgeschlagen ist, erstellte das Malware eine öffentliche Repository innerhalb des Opfer-GitHub-Kontos und lud die gestohlenen Materialien dort als Release-Asset hoch, was bedeutet, dass einige Organisationen ihre eigenen Geheimnisse im Klartext veröffentlichten.

Warum das Risiko den Paket-Entfernen überdauerte

Die Entfernung der schädlichen Versionen aus PyPI schloss das Ereignis nicht ab. Jede während der Aktivität des vergifteten Pakets kopierte Anmeldeinformationen bleibt gültig, bis der Besitzer sie rotiert oder widerruft, und die Entfernung des Pakets hat allein keinen Effekt. Das FBI machte denselben Punkt in einer am 2. Juli 2026 veröffentlichten FLASH-Advisory zu TeamPCP deutlich, indem es warnte, dass Organisationen, die von der Kampagne betroffen waren, exfiltratede Daten und Anmeldeinformationen als anhaltendes Risiko behandeln sollten, da damit verbundene Akteure diese wahrscheinlich lange nach dem ursprünglichen Eindringen als Waffe einsetzen werden.

Die Advisory bestätigt den Umfang der Kampagne über LiteLLM hinaus: TeamPCP trojanisierte Trivy, Checkmarx’ KICS-Scanner, LiteLLM und den Telnyx Python SDK, Tools, die in Unternehmenspipelines, Cloud-Infrastrukturen und Sicherheitsworkflows eingebettet sind, und verband die Eindringungen mit Erpressung, indem sie Opfernamen auf einer öffentlichen Leak-Seite veröffentlichten und drohten, gestohlene Daten offenzulegen.

Die vom FBI empfohlenen Abhilfemaßnahmen überschneiden sich fast genau mit dem, was die LiteLLM-Kette ausgenutzt hat: GitHub-Aktionen an verifizierte Commit-Hashes anstatt an schwimmende Versionstags binden, jedes CI/CD-Geheimnis und jeden Veröffentlichungsschlüssel, der während des Expositionszeitraums zugänglich war, rotieren, least-privilege-Scope auf Service-Conten und Registrierungstoken durchsetzen und GitHub-Organisationen nach Repositories mit den Namen tpcp-docs oder docs-tpcp suchen, die das Malware mit gestohlenen Anmeldeinformationen erstellt.

Was die Konfidenzlabels bedeuten

CloudSEK sortiert die Organisationen in seinem Datensatz nach Beweisstärke. Eine hohe Konfidenz basiert auf identifizierbaren Unternehmensdomänen, Repositories, Anmeldeinformationen oder Infrastrukturen; eine mittlere Konfidenz weist glaubwürdige, aber schwächere Indikatoren auf. Keine dieser Labels ist Beweis für einen erfolgreichen Angriff, und das Unternehmen betont, dass der Datensatz rekonstruierte Exposition ist: Einträge bedeuten, dass mit der Organisation verknüpfte Informationen identifiziert und untersucht werden sollten, nicht, dass ein Einbruch bestätigt ist.

Einige Vorsicht hinsichtlich des Umfangs ist angebracht. Die Zahlen von 2.500 Organisationen und 434.000 Pipelines stammen aus einem Datensatz, den CloudSEK durch seine Intelligence-Kanäle erlangt und rekonstruiert hat, und das Unternehmen verkauft die Expositions-Überwachungsplattform AIVigil, auf die diese Forschung hinweist. Keines davon untergräbt die Kampagne darunter: Der LiteLLM-Kompromiss, seine Position im weiteren TeamPCP-Betrieb und die betroffenen Anmeldeinformationen werden durch die FBI-Advisory und den Ereignisrekord aus März bestätigt.

CloudSEK hat einen kostenlosen Expositions-Prüfer veröffentlicht, mit dem Organisationen überprüfen können, ob ihre Infrastruktur im Datensatz erscheint. Die Empfehlung für jeden Treffer ist, jede Anmeldeinformation, die der betroffene Prozess lesen konnte, als potenziell exponiert zu behandeln, bis sie validiert ist, Zugriffsprotokolle über Cloud-, Quellcode-, Registrierungs- und Cluster-Systeme überprüfen und breit rotieren, anstatt nur den LiteLLM- oder Model-Provider-Schlüssel zu rotieren. Für Organisationen, die im März die betroffenen Versionen ausgeführt haben, läuft die Rotationsentscheidung bereits seit fünf Monaten.