Der 40-Minuten-Angriff, der über 2.500 Unternehmen enttarnte

Im März 2026 wurde ein nur 40-minütiges Zeitfenster auf PyPI zum Auslöser der bislang größten Supply-Chain-Attacke auf KI-Infrastruktur des Jahres. Die Hackergruppe TeamPCP veröffentlichte zwei manipulierte Versionen von LiteLLM, einem viel genutzten Open-Source-KI-Proxy-Gateway. Die anschließende Exfiltration von Zugangsdaten betraf mehr als 2.500 Organisationen weltweit – darunter Amazon, Microsoft, Cisco, NVIDIA und Samsung. Dies ist die vollständige Chronologie, die Angriffsmechanismen und die Folgen des Vorfalls.

Angriffs-Chronologie

Der Angriff erstreckte sich über mehrere Tage im März 2026 und basierte auf einer Kaskade von Kompromittierungen vertrauenswürdiger Sicherheitstools. Die wichtigsten Daten sind:

• 19. März 2026 – TeamPCP kompromittierte Aqua Securitys Trivy, einen beliebten Open-Source-Schwachstellenscanner, der in CI/CD-Pipelines eingesetzt wird. Die Gruppe nutzte eine unvollständig widerrufene Berechtigung bei Aqua Security, um schädliche Commits in 76 von 77 trivy-action-Versionstags und alle sieben setup-trivy-Tags zu erzwingen . Dieser Vorfall erhielt die CVE-Nummer CVE-2026-33634 .
• 24. März 2026, ~10:39 UTC – LiteLLM Version 1.82.7 wurde auf PyPI veröffentlicht. Der schädliche Code wurde während des eigenen CI/CD-Build-Prozesses von LiteLLM injiziert, da die Pipeline den nun vergifteten Trivy-Scanner automatisch als Teil ihres Sicherheits-Scanning-Workflows installierte .
• 24. März 2026, ~10:39–11:19 UTC – Auch Version 1.82.8 wurde hochgeladen. Die Hintertür in diesen Paketen führte eine Nutzdaten aus, die Zugangsdaten stahlen – darunter Cloud-Zugangsdaten, SSH-Schlüssel, Kubernetes-Konfigurationen, Datenbank-Zugangsdaten, API-Schlüssel und andere Geheimnisse – und diese an den entfernten Server von TeamPCP übermittelte . Version 1.82.8 war besonders gefährlich: Sie installierte eine .pth-Datei, die die Nutzdaten bei jedem Python-Aufruf ausführte, selbst wenn LiteLLM nie explizit importiert wurde .
• 24. März 2026, ~11:19 UTC – PyPI stellte das LiteLLM-Projekt unter Quarantäne, etwa 40 Minuten nach dem Hochladen der ersten schädlichen Version. Das LiteLLM-Team riet jedoch, jede Installation bis 16:00 UTC desselben Tages als verdächtig zu betrachten . Die Pakete wurden in dem etwa 2,5-stündigen Fenster bis zur vollständigen Wirksamkeit der Quarantäne über 119.000 Mal heruntergeladen .

TeamPCP nutzte die gestohlenen PyPI-Veröffentlichungs-Anmeldedaten, um diese Versionen direkt auf PyPI zu bringen und dabei den normalen GitHub-basierten Release-Prozess von LiteLLM zu umgehen . Die Gruppe fügte in diesem Zeitfenster weitere schädliche Aktivitäten hinzu, darunter die Verunstaltung von 15 Organisations-Repositories, die Löschung von 182 persönlichen Repos und die öffentliche Zugänglichmachung von 70 privaten BerriAI-Repositories (der Muttergesellschaft von LiteLLM) .

Wie der Angriff funktionierte: Eine kaskadenartige Supply-Chain-Kompromittierung

Der Angriff ist ein Lehrbuchbeispiel für eine kaskadenartige Supply-Chain-Kompromittierung. TeamPCP griff LiteLLM nicht direkt an. Stattdessen nutzten sie eine Vertrauenskette aus:

1. Erste Kompromittierung: Trivy – Am 19. März verschaffte sich TeamPCP Zugang zur Trivy GitHub Actions Pipeline, indem sie eine Berechtigung nutzten, die zwar rotiert, aber nicht vollständig widerrufen worden war . Sie veröffentlichten schädliche Trivy-Versionen, die eine Nutzdaten zum Stehlen von Zugangsdaten in jeden CI/CD-Runner injizierten, der den kompromittierten Scanner installierte.
2. Zweite Kompromittierung: LiteLLM – Die eigene CI/CD-Pipeline von LiteLLM installierte den Trivy-Schwachstellenscanner automatisch als Sicherheitsschritt. Als die Pipeline am 24. März lief, zog sie die vergiftete Trivy-Version. Die schädlichen Nutzdaten in Trivy durchsuchten die Umgebung des CI-Runners und extrahierten die PyPI-Veröffentlichungs-Token und GitHub-Zugangsdaten von LiteLLM .
3. Dritte Kompromittierung: PyPI-Benutzer – Mit den PyPI-Zugangsdaten von LiteLLM veröffentlichte TeamPCP schädliche LiteLLM-Versionen auf PyPI. Jeder Entwickler oder jede Organisation, die

   pip install litellm==1.82.7

   oder 1.82.8 ausführte – oder deren CI/CD-Pipeline automatisch die neueste Version zog – ließ ihre Build-Umgebung nach Geheimnissen durchsuchen.

Wie CloudSEK anmerkte: „Der Angriff ging von der Trivy-Abhängigkeit aus, die in [LiteLLMs] CI/CD-Sicherheits-Scanning-Workflow verwendet wurde“ . Es gibt keine CVE für die LiteLLM-Kompromittierung selbst, da nichts im Code von LiteLLM anfällig war; die Schwachstelle lag in der Vertrauensbeziehung zwischen der Build-Pipeline von LiteLLM und ihrem Sicherheits-Scanning-Tool .

Ausmaß der Datenexfiltration

Das volle Ausmaß des Datendiebstahls wurde erst fünf Monate später klar, als mehrere Threat-Intelligence-Firmen ihre Analysen veröffentlichten:

• Hudson Rock erhielt unabhängig und analysierte das rohe Exfiltrationsarchiv der Angreifer: eine 153 GB große RAR-Datei mit genau 433.909 Dateien und 118.829 CI-Runner-Dumps, die 2.488 Unternehmensdomains zugeordnet wurden .
• CloudSEK rekonstruierte etwa 434.000 erfasste CI/CD-Pipeline-Dateien und identifizierte über 2.500 potenziell exponierte Organisationen . CloudSEK bezeichnete den Vorfall als die bislang größte Supply-Chain-Attacke auf KI-Infrastruktur im Jahr 2026 .
• Die kompromittierten Daten umfassten Cloud-Plattform-Zugangsdaten (AWS, GCP, Azure), KI-Anbieter-API-Schlüssel (OpenAI, Anthropic, Cohere etc.), private SSH-Schlüssel, Kubernetes-Service-Account-Token, Docker-Registry-Logins, .env-Dateien, Datenbank-Verbindungsstrings, Slack-Signing-Secrets, Salesforce-Client-Secrets und Git-Zugangsdaten .

Das FBI gab am 2. Juli 2026 ein Flash-Advisory (FLASH-20260702-01) heraus, das davor warnte, dass verbundene Akteure die während der TeamPCP-Kampagne exfiltrierten Zugangsdaten noch lange nach der ursprünglichen Kompromittierung nutzen könnten. Es forderte Organisationen auf, CI/CD-Secrets, Veröffentlichungs-Token und Cloud-Zugangsdaten, die während der relevanten Expositionsfenster zugänglich waren, zu rotieren .

Betroffene Organisationen

Zu den exponierten Domains gehörten große Unternehmen aus den Bereichen Technologie, Finanzen, Industrie und Telekommunikation. Bestätigte namentlich genannte Organisationen aus mehreren Quellen sind :

• Technologie: Amazon (AWS), Microsoft, NVIDIA, Cisco Systems, Samsung Electronics, Salesforce, ServiceNow, X Corp (ehemals Twitter), Zscaler, Roku, Epic Games
• Industrie: Volkswagen, Siemens, FedEx
• Finanzen: S&P Global, Deloitte
• Telekommunikation: BT Group, Vodafone

CloudSEKs Datensatz enthielt „High-Confidence-Matches“, die mit Unternehmensdomains, Repositories, Zugangsdaten oder Infrastruktur dieser Organisationen verbunden waren . Hudson Rock stellte fest, dass das Archiv für viele dieser Organisationen Monate nach dem Vorfall noch „gültige“ Zugangsdaten enthielt .

Kevin Beaumonts Tests nach dem Vorfall

Fünf Monate nach dem Vorfall führte der unabhängige Sicherheitsforscher Kevin Beaumont eine wichtige Realitätsprüfung durch. Nach dem Ars-Technica-Bericht über den Vorfall testete Beaumont kompromittierte Zugangsdaten eines großen US-Technologieunternehmens, das öffentlich erklärt hatte, es habe „alles rotiert“. Unter Einhaltung einer Richtlinie zur verantwortungsvollen Offenlegung testete er die Zugangsdaten und stellte fest, dass „fast alle funktionierten“ – was bedeutet, dass die Organisation ihre kompromittierten Geheimnisse trotz gegenteiliger Behauptungen nicht tatsächlich ausgetauscht hatte .

Diese Erkenntnis unterstreicht eine entscheidende Lehre: Aussagen über die Rotation von Zugangsdaten und die tatsächliche Rotation sind oft zweierlei, und die gestohlenen Zugangsdaten aus diesem Angriff bleiben eine aktive Bedrohung.

Dringende Empfehlung

Behandeln Sie alle Geheimnisse, API-Schlüssel, Cloud-Zugangsdaten, SSH-Schlüssel, Kubernetes-Konfigurationen und andere sensible Daten, die für LiteLLM-Versionen 1.82.7 oder 1.82.8 zugänglich waren, als vollständig kompromittiert. Die sofortige Rotation aller Zugangsdaten, die während des Fensters vom 24. März 2026 hätten exponiert sein können, ist unerlässlich – unabhängig davon, ob eine Organisation glaubt, sie bereits rotiert zu haben .

Der Angriff gilt als der größte KI-Infrastruktur-Supply-Chain-Breach des Jahres 2026, und die gestohlenen Daten bleiben eine anhaltende Bedrohung für Folgeangriffe, wie Beaumonts Tests gezeigt haben . Das FBI hat davor gewarnt, dass Folgeangriffe wahrscheinlich sind, und der Schatz gültiger Zugangsdaten in dem 153-GB-Archiv ist ein ständiges Geschenk für Bedrohungsakteure.

Wenn Ihre Organisation LiteLLM am 24. März 2026 in irgendeiner Weise genutzt hat, gehen Sie von einer Kompromittierung aus. Überprüfen Sie auf die schädliche .pth-Datei (litellm_init.pth) und die Persistenz-Hintertür (~/.config/sysmon/sysmon.py), verifizieren Sie die installierte Version mit

pip show litellm