Das Wichtigste in Kürze
Am 24. März 2026 manipulierte die als TeamPCP (UNC6780) geführte Angreifergruppe die LiteLLM-Versionen 1.82.7 und 1.82.8 auf PyPI. Zuvor hatte sie den Scanner Trivy von Aqua Security kompromittiert, der PyPI-Veröffentlichungsdaten aus der CI-Pipeline von LiteLLM verwaltete. Die präparierten Pakete waren rund 40 Minuten verfügbar. Das Threat-Intelligence-Unternehmen CloudSEK veröffentlichte am 11. August seine vollständige Expositionsanalyse: mehr als 2.500 Organisationen und etwa 434.000 CI/CD-Pipelines sind potenziell betroffen. Das FBI warnte bereits im Juli 2026 in einem FLASH-Hinweis, dass gestohlene Zugangsdaten möglicherweise noch nicht rotiert wurden und für Folgeangriffe nutzbar sind.
Die Schwachstelle CVE-2026-33634 (CVSS: kritisch) wurde am 26. März 2026 in den CISA-Katalog der Known Exploited Vulnerabilities aufgenommen. Wer LiteLLM im Zeitfenster vom 24. März in einer Build-Pipeline eingesetzt und die zugehörigen Secrets noch nicht vollständig rotiert hat, hat den Vorfall nicht abgeschlossen.
Wie Trivy zum Einfallstor wurde
Der Angriff nutzte ein einziges, nie widerrufenes Token, das drei Ebenen tief in einer Open-Source-Abhängigkeitskette steckte. TeamPCP kompromittierte am 19. März 2026 zunächst den Schwachstellenscanner Trivy von Aqua Security und erhielt so Zugriff auf ein PyPI-Token, das die CI-Pipeline von LiteLLM für automatisierte Releases verwendete. Als das Build-System von LiteLLM Trivy im regulären Release-Workflow ausführte, schleuste der kompromittierte Scanner Schadcode in das ausgehende Paket ein.
Ergebnis waren die LiteLLM-Versionen 1.82.7 und 1.82.8, veröffentlicht am 24. März auf PyPI. Beide enthielten eine Datei namens litellm_init.pth, die Python über den .pth-Mechanismus beim Start jedes Python-Prozesses automatisch lädt – der Credential-Harvester lief also auch dann, wenn LiteLLM nie direkt importiert wurde. Die Schadpakete waren etwa 40 Minuten verfügbar (ungefähr 10:39 bis 16:00 Uhr UTC), bevor PyPI sie entfernte.
Das Angriffsmuster zeigt deutlich, wo das CI/CD-Risiko heute liegt. Ziel war nicht LiteLLM selbst, sondern ein Sicherheitswerkzeug, dem LiteLLM blind vertraute und dessen Zugangsdaten nie auf Lesezugriff oder eine begrenzte Laufzeit beschränkt waren. Ein einziges nicht rotiertes Token in der Release-Pipeline eines Scanners wurde innerhalb einer Stunde zu einem vergifteten Paket, das an eine unbekannte Zahl nachgelagerter Build-Systeme ausgeliefert wurde.
Was der CloudSEK-Bericht zeigt
CloudSEK rekonstruierte die Exposition in seiner Analyse vom 11. August 2026 anhand von rund 434.000 Dateien, die auf der Infrastruktur der Angreifer sichergestellt wurden. Mehr als 2.500 Organisationen stuft das Unternehmen als Treffer mit hoher Konfidenz ein: Ihre Build-Umgebungen weisen Spuren einer Installation der präparierten Releases im aktiven Zeitfenster auf.
Zu den namentlich genannten Organisationen im High-Confidence-Datensatz gehören NVIDIA, Amazon Web Services, Cisco Systems, Samsung Electronics, Salesforce, Deloitte, Siemens, S&P Global, ServiceNow, Vodafone, Volkswagen, FedEx, Thales, Zscaler und die London Stock Exchange Group. Die Breite der Liste zeigt, wie verbreitet LiteLLM als KI-Gateway-Bibliothek in Branchen von Enterprise-SaaS bis zur Logistikinfrastruktur ist.
Wichtige Einschränkung im CloudSEK-Bericht: Die Zahl von über 2.500 beschreibt eine rekonstruierte Exposition, keine bestätigte Kompromittierung. CI/CD-Pipelines installieren und cachen Pakete unterschiedlich. Ob eine Installation Folgen hatte, hängt davon ab, ob im Zeitfenster tatsächlich ein Python-Prozess gestartet wurde, welche Secrets in der Umgebung erreichbar waren und ob eine Netzwerkverbindung zur Angreifer-Domain bestand. Teams sollten ihre eigenen Build-Logs auswerten, statt auf eine offizielle Benachrichtigung zu warten.
Was abgeflossen ist und warum es weiter zählt
Der Harvester in litellm_init.pth zielte auf ein breites Spektrum an Zugangsdaten und Umgebungszuständen: Cloud-API-Schlüssel einschließlich OpenAI- und Anthropic-Tokens, AWS-Access- und Secret-Keys, Azure-Zugangsdaten, GCP-Service-Account-Tokens, Kubernetes-ServiceAccount-Tokens, private SSH-Schlüssel, Datenbankpasswörter sowie allgemeine Umgebungsvariablen, die beim Start des Python-Prozesses erfasst wurden. Alle Daten gingen an eine von TeamPCP kontrollierte Domain – models.litellm[.]cloud –, die einen legitimen LiteLLM-Endpunkt imitierte.
Der FBI-Hinweis vom Juli 2026 ist deshalb so wichtig, weil die Rotation von Zugangsdaten nach einem Lieferkettenvorfall langsamer und lückenhafter verläuft, als sie sollte. Secrets, die in ausgerollten Containern stecken, in CI/CD-Secret-Stores ohne automatische Rotation liegen oder von mehreren Diensten geteilt werden, gehen bei der Incident Response häufig unter. Der Hinweis betont ausdrücklich, dass abgegriffene API-Schlüssel von KI-Anbietern wie OpenAI und Anthropic besonders riskant sind: Mit ihnen lässt sich unbemerkt Inferenz auf fremde Kosten betreiben oder Schadausgabe in KI-gestützte Workflows einschleusen, ohne klassische Intrusion-Detection-Signale auszulösen.
Laut CloudSEK nutzte TeamPCP zudem nachgelagerte Infrastruktur – GitHub- und GitLab-Repositories namens tpcp-docs oder docs-tpcp – für fortlaufendes Command-and-Control. Einige kompromittierte Umgebungen könnten also einen aktiven Persistenzmechanismus haben, der den ursprünglichen Datendiebstahl überdauert.
Was das für den DACH-Markt bedeutet
Für Deutschland, Österreich und die Schweiz ist der Fall kein fernes US-Thema: Mit Siemens und Volkswagen stehen zwei der größten Industriekonzerne der Region auf der CloudSEK-Liste, und LiteLLM ist auch im Mittelstand ein gängiger Baustein, um mehrere LLM-Anbieter – etwa US-Modelle neben europäischen oder selbst gehosteten – hinter einer Schnittstelle zu bündeln. Solche Gateways entstehen häufig als Pilotprojekt eines Data- oder KI-Teams und tauchen dann weder im Asset-Inventar noch in der Software-Stückliste (SBOM) auf. Genau diese Lücke macht eine Prüfung der Build-Umgebungen jetzt dringlich.
Für Teams, die KI-gestützte Produkte entwickeln, zeigt der LiteLLM-Vorfall eine Risikoklasse, die wächst, je mehr KI-Bibliotheken zur Basisinfrastruktur werden: Die Vertrauenskette eines Python-Pakets umfasst jedes Werkzeug in der Release-Pipeline seines Herausgebers, nicht nur das Paket selbst. LiteLLM hat den Schadcode nicht geschrieben. Das Build-System zog eine kompromittierte Abhängigkeit automatisch – genau so, wie es konzipiert war. Der Angriff gelang, gerade weil die Automatisierung wie vorgesehen funktionierte.
Praktisch heißt das: Dependency-Audits müssen über direkte Abhängigkeiten und deren transitiven Graphen hinausgehen. Build-Werkzeuge – Scanner, Formatter, Linter, Test-Runner –, die Veröffentlichungsrechte halten oder mit Zugriff auf Secrets laufen, brauchen dieselben Rotations- und Least-Privilege-Regeln wie Anwendungs-Secrets. Ein Trivy-Token mit Schreibrechten auf PyPI sollte es nicht geben; falls doch, muss es eng begrenzt, zeitlich befristet und in kürzeren Abständen rotiert werden, als ein Angreifer unentdeckt im System bleiben kann.
Regulatorisch sind in der DACH-Region vor allem zwei Regelwerke berührt. Unternehmen im Anwendungsbereich von NIS2 sollten den Vorfall gegen ihre Meldepflichten prüfen: Erhebliche Sicherheitsvorfälle sind innerhalb von 24 Stunden nach Kenntnisnahme frühzeitig zu melden – in Deutschland an das BSI. Für Banken, Versicherer und andere von der BaFin beaufsichtigte Finanzunternehmen gelten zusätzlich die Vorgaben von DORA zu IKT-Vorfällen und IKT-Drittparteienrisiken; ein Open-Source-Gateway in der Build-Kette gehört in diese Risikobetrachtung. Wer seine März-Exposition erst jetzt über den CloudSEK-Bericht erkennt, sollte die Meldefristen mit Rechts- und Compliance-Abteilung klären. Enthielten die abgeflossenen Umgebungsvariablen personenbezogene Daten oder Zugänge zu ihnen, ist zudem die 72-Stunden-Frist der DSGVO gegenüber der zuständigen Datenschutzaufsicht zu prüfen.
Besonders für FinTech- und HealthTech-Unternehmen gilt: Ein KI-API-Schlüssel, der aus einer Build-Pipeline gestohlen wurde, die gleichzeitig Gesundheitsdaten oder Umgebungsvariablen der Zahlungsabwicklung verarbeitete, ist ein doppeltes Risiko. Der OpenAI- oder Anthropic-Schlüssel selbst mag wenig wert sein – doch der mit ihm abgeflossene Umgebungsvariablen-Dump kann Produktions-Datenbankpasswörter oder Zugangsdaten für PCI-relevante Dienste enthalten.
Drei Schritte zur Bereinigung
Wenn Ihre Organisation LiteLLM nutzt und noch keine Nachbetrachtung des Vorfalls abgeschlossen hat, priorisieren Sie diese drei Maßnahmen:
1. Build-Logs für das Expositionsfenster prüfen. Durchsuchen Sie die Artefakt-Logs Ihrer CI/CD-Plattform nach Installationen von litellm==1.82.7 oder litellm==1.82.8 am 24. März 2026 zwischen etwa 10:39 und 16:00 Uhr UTC. Nutzt Ihre Pipeline Caching, prüfen Sie auch, ob gecachte Versionen aus diesem Fenster in späteren Builds wiederverwendet wurden.
2. Alle Secrets betroffener Pipelines rotieren. Dazu gehören API-Schlüssel der Cloud-Anbieter (AWS, Azure, GCP), API-Schlüssel der KI-Anbieter (OpenAI, Anthropic und jeder weitere Anbieter, dessen Zugangsdaten in Umgebungsvariablen lagen), Kubernetes-ServiceAccount-Tokens, SSH-Schlüssel des Build-Runners und Datenbankpasswörter, auf die die Build-Umgebung zugreifen konnte. Beschränken Sie die Rotation nicht auf Secrets, die Ihrer Meinung nach direkt genutzt wurden – rotieren Sie alles, was im Zugriffsbereich des Python-Prozesses lag.
3. Nach Persistenz-Indikatoren suchen. Durchsuchen Sie Ihre GitHub- und GitLab-Organisationen nach Verweisen auf die Repositories tpcp-docs oder docs-tpcp. Prüfen Sie die Netzwerk-Logs der Build-Runner auf ausgehende Verbindungen zu models.litellm.cloud ab dem 24. März. Finden Sie einen dieser Indikatoren, behandeln Sie die betroffene Build-Umgebung als möglicherweise weiterhin kompromittiert und ziehen Sie Incident-Response-Kapazitäten hinzu.
Häufige Fragen
Welche LiteLLM-Versionen waren betroffen?
Mit einer Hintertür versehen waren die LiteLLM-Versionen 1.82.7 und 1.82.8, veröffentlicht am 24. März 2026 auf PyPI. Beide wurden inzwischen entfernt. Jeder Build, der diese Versionen im rund 40-minütigen Zeitfenster (etwa 10:39 bis 16:00 Uhr UTC) installiert hat, könnte Zugangsdaten preisgegeben haben. Prüfen Sie die Pipeline-Logs auf Installationen an diesem Datum und in diesem UTC-Fenster.
Wie gelangten die Angreifer in die Release-Pipeline von LiteLLM?
TeamPCP kompromittierte am 19. März 2026 zunächst Trivy, einen weit verbreiteten Open-Source-Sicherheitsscanner von Aqua Security, und erlangte so PyPI-Veröffentlichungsdaten, die die CI-Pipeline von LiteLLM für automatisierte Releases nutzte. Die Angreifer fügten eine bösartige Datei (litellm_init.pth) ein, die beim Start von Python automatisch ausgeführt wurde – ohne direkten Import von LiteLLM.
Welche Zugangsdaten wurden gestohlen?
Die Hintertür sammelte Cloud-API-Schlüssel (OpenAI, Anthropic, AWS, Azure, GCP), Kubernetes-ServiceAccount-Tokens, SSH-Schlüssel, Datenbankpasswörter und Umgebungsvariablen – alles ging an eine von den Angreifern kontrollierte Domain. Jedes Secret, auf das ein Python-Prozess mit den betroffenen Paketen im Expositionsfenster zugreifen konnte, ist als kompromittiert zu behandeln.
Warum ist das im August 2026 noch relevant?
Das FBI veröffentlichte im Juli 2026 einen FLASH-Hinweis, wonach gestohlene Zugangsdaten möglicherweise noch nicht rotiert wurden und nutzbar bleiben. Der CloudSEK-Bericht vom 11. August bestätigte, dass einige Treffer mit hoher Konfidenz den Vorfall nicht öffentlich eingeräumt hatten. Für Organisationen, die seit März keine Bereinigung abgeschlossen haben, besteht das Risiko aktiver Zugangsdaten fort.
Was sollten Teams tun, die LiteLLM im März 2026 genutzt haben?
Drei Schritte: (1) Pipeline-Logs auf Installationen von litellm==1.82.7 oder litellm==1.82.8 am 24. März (UTC) prüfen. (2) Alle Secrets rotieren, auf die diese Build-Umgebungen zugreifen konnten – Cloud-Schlüssel, Kubernetes-Tokens, SSH-Schlüssel, Datenbankpasswörter. (3) Repositories nach Verweisen auf tpcp-docs oder docs-tpcp durchsuchen und die Logs der Build-Runner auf ausgehende Verbindungen zu models.litellm.cloud prüfen.
Quellen
SecurityWeek — Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack, August 2026
The Hacker News — Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations, August 2026
CloudSEK — 2,500+ Companies and 434,000 CI/CD Pipelines Exposed (Primärquelle), 11. August 2026