153 GB gestohlen: Wie eine KI-Bibliothek AWS, Samsung & 2.500 Konzerne in 40 Minuten bloßstellte
BREAKING
FBI-Warnung aktiv · FLASH-20260702-01 · Angriff noch immer live
LiteLLM Hack: AWS, Samsung & 2.500 Firmen in 40 Minuten
TeamPCP vergiftete LiteLLM – die meistgenutzte Open-Source-KI-Bibliothek der Welt mit 95 Millionen monatlichen Downloads – und stahl in weniger als einer Stunde Cloud-Zugangsdaten, SSH-Keys und KI-API-Tokens von 2.488 Unternehmen. Die FBI-Warnung vom Juli 2026 sagt: Die gestohlenen Credentials sind immer noch aktiv. Und der nächste Angriff kommt.
2.500+
Betroffene Unternehmen
434.000
CI/CD-Pipelines exponiert
153 GB
Gestohlene Daten
40 Min.
Schadcode auf PyPI
95 Mio.
Monatliche Downloads
⚠️ Live
FBI-Warnung aktiv
🤖 Was ist LiteLLM – und warum nutzt es fast jeder?
LiteLLM ist eine Open-Source-Python-Bibliothek, die als einheitliches Gateway zu über 100 KI-Modellen fungiert – von OpenAI über Anthropic und Google bis zu AWS Bedrock. Entwickler müssen damit nicht mehr für jedes Modell eigenen Code schreiben: Ein einziger Aufruf, ein einheitliches Format, beliebiges Modell. Mit 95 Millionen monatlichen Downloads, 40.000 GitHub-Stars und 240 Millionen Docker-Pulls ist LiteLLM das meistgenutzte KI-Gateway der Welt – und eine direkte Abhängigkeit von CrewAI, DSPy, Browser-Use, Mem0, Guardrails und fast jedem anderen wichtigen KI-Agent-Framework. Wer in 2026 eine KI-Anwendung baut, hat sehr wahrscheinlich LiteLLM im Stack.
Was passiert ist – in der Kurzfassung
Am 24. März 2026 um 10:39 UTC veröffentlichte die Hackergruppe TeamPCP zwei manipulierte Versionen der Python-Bibliothek LiteLLM – 1.82.7 und 1.82.8 – auf dem offiziellen Python Package Index (PyPI). Innerhalb von weniger als 40 Minuten hatten Tausende von automatisierten Build-Systemen, Entwicklungs-Pipelines und Produktionsservern die vergifteten Pakete heruntergeladen und ausgeführt. Was folgte, war der größte KI-Supply-Chain-Angriff des Jahres 2026.
Der Schadcode war dreigliedrig: Zuerst durchsuchte er die Umgebung systematisch nach Zugangsdaten – Cloud-Keys für AWS, Google Cloud und Azure, SSH-Schlüssel, Kubernetes-Tokens, CI/CD-Secrets und LLM-API-Keys. Dann versuchte er, sich lateral durch Kubernetes-Cluster zu bewegen. Und schließlich installierte er eine persistente systemd-Hintertür, die regelmäßig Befehle von einem Command-and-Control-Server der Angreifer abholte.
40 Minuten klangen zunächst nach einem engen Fenster. Die Realität war dramatisch anders: Automatisierte Build-Systeme, gepinnlose Abhängigkeiten und gecachte Pakete sorgten dafür, dass der Schadcode weit über diesen Zeitraum hinaus ausgeführt wurde. Und der eigentliche Einstiegspunkt lag noch früher – Ende Februar 2026, fast einen Monat vor dem PyPI-Upload.
Wie der Angriff funktionierte: Eine Kette aus drei Werkzeugen
Was TeamPCP auszeichnet, ist die Raffinesse ihrer Angriffskette. Sie haben nie direkt LiteLLM angegriffen. Stattdessen nutzten sie eine Schwachstelle in einem Sicherheitswerkzeug – um am Ende die Schlüssel zu Tausenden von Unternehmensinfrastrukturen zu stehlen.
01
Trivy-Kompromittierung (Ende Februar 2026)
Ein Angreifer mit dem Handle hackerbot-claw nutzte eine Fehlkonfiguration im pull_request_target-Workflow von Trivy – dem meistgenutzten Open-Source-Vulnerability-Scanner. Damit erbeutete er einen privilegierten Personal Access Token von Aqua Security, Trivys Entwickler. Aqua rotierte zwar die Credentials – aber nicht atomar. Ein Restschlupf blieb bestehen.
↓
02
LiteLLMs CI-Pipeline wird vergiftet (24. März 2026)
LiteLLMs Build-System nutzte Trivy – ohne eine spezifische, vertrauenswürdige Version zu pinnen. Als die poisoned Trivy-Version in die Pipeline installiert wurde, stahl sie LiteLLMs PyPI-Publishing-Token. TeamPCP hatte jetzt die Schlüssel, um beliebige Pakete unter dem Namen litellm auf PyPI zu veröffentlichen – und niemand wäre zunächst gewarnt worden.
↓
03
Schadcode landet auf Millionen Geräten (24. März, 10:39 UTC)
Versionen 1.82.7 und 1.82.8 wurden auf PyPI hochgeladen. Beide enthielten identischen Schadcode – mit einem entscheidenden Unterschied: Version 1.82.7 erforderte, dass LiteLLM aktiv importiert wurde. Version 1.82.8 – 13 Minuten später veröffentlicht – lief bereits beim Python-Start, vollständig unabhängig davon, ob LiteLLM überhaupt genutzt wurde. CVE-2026-33634 wurde am 26. März in CISAs KEV-Katalog aufgenommen.
Was konkret gestohlen wurde
- AWS-Credentials (Access Keys, Secret Keys, Session Tokens)
- Google Cloud Platform Service Account Keys
- Microsoft Azure Service Principal Credentials
- Kubernetes-Cluster-Tokens und -Konfigurationen
- SSH-Schlüssel für Server- und Repository-Zugang
- Environment-Variablen aus Build-Umgebungen
- GitHub/GitLab Personal Access Tokens
- PyPI-Publishing-Credentials weiterer Pakete
- CI/CD-Pipeline-Secrets (Jenkins, GitHub Actions, GitLab CI)
- Repository-Credentials und Deploy-Keys
- Docker-Registry-Passwörter
- Datenbankverbindungsstrings aus Runtime-Umgebungen
- OpenAI API-Keys (GPT-5, DALL-E, Embeddings)
- Anthropic API-Keys (Claude-Modelle)
- Google Vertex AI / Gemini Credentials
- AWS Bedrock-Konfigurationen und Zugangstoken
- Cohere, Mistral, Together AI-Keys
- Proprietäre LLM-Endpoints interner Modelle
⚠️
Wichtiger Hinweis: Expositionsnachweis ≠ Bestätiger EinbruchCloudSEK und Hudson Rock haben einen 153-GB-Datensatz analysiert und über 2.500 Unternehmensdomains mit dem Angriff verknüpft. Eine „high-confidence“-Übereinstimmung bedeutet, dass starke Beweise eine Organisation mit dem Angriffsweg verbinden – nicht zwangsläufig, dass Credentials erfolgreich gestohlen oder missbraucht wurden. Jedes betroffene Unternehmen muss seine eigene Exposition individuell prüfen.
Wer ist TeamPCP – und warum LiteLLM?
TeamPCP ist eine finanziell motivierte Bedrohungsgruppe, die von Google unter dem Bezeichner UNC6780 geführt wird. Die Gruppe ist auf Software-Supply-Chain-Angriffe spezialisiert – insbesondere auf die Kompromittierung von Sicherheitswerkzeugen und Entwicklerbibliotheken, die tief in Unternehmens-Pipelines eingebettet sind. Vor LiteLLM kompromittierte TeamPCP bereits Trivy (Aqua Securitys Vulnerability-Scanner), Checkmarx‘ KICS-Scanner und das Telnyx Python SDK. Die gestohlenen Credentials werden auf Telegram gehandelt und sind mit einem Ransomware-Affiliate-Programm verknüpft.
Warum LiteLLM? Die Logik ist brutal einfach: LiteLLM ist das Nervenzentrum moderner KI-Entwicklung. Die Bibliothek sitzt zwischen dem Code eines Unternehmens und seinen KI-Providern – und berührt dabei zwangsläufig die sensibelsten Credentials in der gesamten Infrastruktur. Wer LiteLLMs Publishing-Credentials hat, kann ein manipuliertes Paket unter dem vertrauenswürdigen Namen veröffentlichen. Und wer in LiteLLMs Laufzeitumgebung sitzt, hat Zugriff auf die Schlüssel zu AWS, Google Cloud, Azure und jedem genutzten KI-Modell.
Besonders heimtückisch: LiteLLM ist nicht nur direkt installiert. Es ist eine transitive Abhängigkeit von fast jedem modernen KI-Agent-Framework – CrewAI, DSPy, Browser-Use, Mem0, Instructor und Camel-AI setzen alle auf LiteLLM. Ein Unternehmen muss also LiteLLM gar nicht selbst einsetzen, um betroffen zu sein. Es reicht, eines dieser Frameworks zu nutzen.
„Trivy, dann das Build-System, dann das LiteLLM-Release: ein einziger nicht-rotierter Token, drei Werkzeuge tief. Diese Kette verwandelt ein einzelnes Credential-Leck in eine ecosystem-weite Exposition.“
— CloudSEK Threat Intelligence, August 2026Zeitlinie: Vom ersten Einbruch zur FBI-Warnung
Ende Februar 2026
Ein Angreifer unter dem Handle hackerbot-claw nutzt eine pull_request_target-Fehlkonfiguration in Trivys GitHub Actions aus. Dabei wird ein privilegierter Personal Access Token von Aqua Security erbeutet. Aqua rotiert zwar Credentials – aber nicht vollständig atomar. Ein Restschlupf bleibt.
24. März 2026, ~10:39 UTC
TeamPCP veröffentlicht LiteLLM Version 1.82.7 auf PyPI. Der Schadcode in proxy_server.py – 12 Zeilen obfuskierter Code – führt sich beim Import aus und beginnt sofort mit der Credential-Ernte. 13 Minuten später folgt Version 1.82.8 mit einem noch aggressiveren Mechanismus: ein .pth-Hook, der bei jedem Python-Start ausgeführt wird – unabhängig davon, ob LiteLLM importiert wird.
24. März 2026, ~16:00 UTC
Die manipulierten Versionen werden von PyPI entfernt. Das offizielle Fenster: unter 40 Minuten. Die reale Exposition ist jedoch viel größer – Cached-Pakete, ungepinnte Dependencies und Offline-Build-Systeme haben die Versionen in Hunderte von Pipelines eingeschleust, die noch Stunden oder Tage weiter laufen.
25.–26. März 2026
Sicherheitsforscher von Cycode, Snyk, Trend Micro und Endor Labs veröffentlichen erste Analysen. CVE-2026-33634 wird am 26. März in CISAs Known Exploited Vulnerabilities Catalog aufgenommen. LiteLLM-Maintainer BerriAI bestätigt den Vorfall und empfiehlt sofort auf Version 1.82.6 oder früher zurückzuwechseln – und alle Credentials zu rotieren.
Mai 2026
Forcepoint X-Labs veröffentlicht eine detaillierte Analyse der Angriffskette. Es wird klar, dass TeamPCP die gleiche Infrastruktur auch gegen Checkmarx‘ KICS-Scanner und das Telnyx Python SDK eingesetzt hat. Der Umfang des Angriffs ist deutlich größer als zunächst angenommen.
2. Juli 2026
Das FBI gibt FLASH-Warnung FLASH-20260702-01 heraus – gerichtet an alle Unternehmen, die potenziell betroffen sein könnten. Kernaussage: Die gestohlenen Credentials sind noch immer aktiv und werden wahrscheinlich von verbundenen Akteuren langfristig genutzt. Weitere Angriffe sind möglich.
August 2026
CloudSEK und Hudson Rock veröffentlichen unabhängige Analysen des 153-GB-Datensatzes. Ergebnis: 2.488 Corporate Domains, 434.000 CI/CD-Pipelines. Zu den identifizierten Unternehmen zählen AWS, Samsung, Nvidia, Cisco, Salesforce, Siemens, Volkswagen, Deloitte, FedEx und über 2.400 weitere.
Offen – Stand 19. August 2026
Keine öffentliche Bestätigung eines tatsächlichen Missbrauchs der gestohlenen Credentials durch betroffene Unternehmen. FBI-Warnung aktiv. Viele der gestohlenen Keys wurden möglicherweise noch nicht rotiert.
MIA
Kostenlose Erstberatung – unverbindlich & persönlich
Ob Managed IT, Cloud-Migration, KI-Infrastruktur oder IT-Sicherheit – wir finden die richtige Lösung für Ihr Unternehmen. Sprechen Sie uns einfach an.
Welche Unternehmen betroffen sind – und in welchen Sektoren
Die Liste der potentiell betroffenen Unternehmen liest sich wie ein Who’s Who der globalen Wirtschaft. CloudSEK und Hudson Rock haben in ihrer Analyse des gestohlenen Datensatzes 2.488 Corporate Domains identifiziert – mit „high confidence“-Übereinstimmungen für die folgenden Organisationen. Wichtig: Eine Übereinstimmung bedeutet Exposition, nicht zwangsläufig einen vollständigen Einbruch.
AWS
Samsung Electronics
Nvidia
Cisco Systems
Salesforce
ServiceNow
HP
Zscaler
X Corp
Epic Games
Siemens
Volkswagen
John Deere
Airbus
Thales
Deutsche Bahn
Boeing
S&P Global
Deloitte
London Stock Exchange
F. Hoffmann-La Roche
Regeneron
Vodafone
Orange
BT Group
FedEx
Roku
Warum 40 Minuten mehr als genug waren
Die intuitive Reaktion auf „40 Minuten“ ist Erleichterung. Die technische Realität ist eine andere. Moderne Software-Entwicklung basiert auf automatisierten Pipelines, die rund um die Uhr laufen – und bei jedem Lauf die neueste Version einer Bibliothek installieren, sofern keine explizite Version angepinnt wurde. In 40 Minuten kann ein populäres Paket in Hunderttausende von Build-Umgebungen, Entwickler-Laptops und Produktionsserver gelangen.
Dazu kommt der Cache-Effekt: Einmal heruntergeladene Pakete werden lokal und in Layer-Caches von Docker, Kubernetes und CI-Systemen gespeichert. Das Entfernen eines Pakets von PyPI stoppt nicht die Ausführung von bereits gecachten Versionen. Und die .pth-Datei, die Version 1.82.8 hinterlässt, führt den Schadcode bei jedem Python-Start aus – nicht nur beim Import von LiteLLM.
🔑
Das eigentliche Problem: Credentials bleiben gültig. Das Entfernen des Schadcodes hilft nur für die Zukunft. Alle Credentials, die in den 40 Minuten – oder danach durch gecachte Versionen – abgegriffen wurden, bleiben gültig, bis das betroffene Unternehmen sie explizit rotiert. Das FBI schätzt, dass ein erheblicher Teil der 2.500 betroffenen Unternehmen dies noch nicht getan hat.
Das FBI warnt ausdrücklich: Verbundene Akteure werden die gestohlenen Credentials voraussichtlich noch lange nach dem ursprünglichen Angriff einsetzen. Weitere Supply-Chain-Angriffe bleiben eine reale Möglichkeit. Organisationen, die LiteLLM 1.82.7 oder 1.82.8 ausgeführt haben, müssen alle potenziell exponierten Credentials als kompromittiert behandeln.
Sofort: Alle Credentials rotieren
CI/CD-Logs ab 24. März prüfen
Auf Persistence-Mechanismen prüfen
litellm_init.pth-Datei suchen & entfernen
Was das für Unternehmen, Entwickler und die KI-Branche bedeutet
Dieser Angriff markiert eine Zäsur. Zum ersten Mal hat ein Supply-Chain-Angriff gezielt die KI-Infrastruktur selbst angegriffen – nicht nur Code-Bibliotheken, sondern das Nervenzentrum moderner KI-Entwicklung. LiteLLM ist nicht irgendeine Bibliothek. Es ist der Knotenpunkt, durch den Millionen von KI-Anfragen laufen, und der dabei zwangsläufig Zugangsdaten zu jedem genutzten KI-Modell berührt.
Für Unternehmen wie Siemens, Volkswagen oder Deutsche Bahn bedeutet die Exposition potenziell kompromittierter Cloud-Credentials mehr als nur einen Datenschutzvorfall. In hochregulierten Umgebungen – Kritische Infrastruktur, Finanzmarkt, Pharma – kann ein einziger gestohlener Kubernetes-Token ausreichen, um Produktionssysteme zu erreichen. Die gestohlenen LLM-API-Keys ermöglichen darüber hinaus unbegrenzte Nutzung auf Kosten der Opfer – oder schlimmer, die Manipulation von KI-Ausgaben in Produktionssystemen.
Für die gesamte Open-Source-KI-Ökosystem ist dies ein Weckruf. Die Geschwindigkeit, mit der KI-Bibliotheken adoptiert werden, übersteigt bei weitem die Sicherheitsreife der meisten Organisationen. Ungepinnte Dependencies, fehlende Package-Signing-Mechanismen und blinder Vertrauen in populäre Pakete sind keine Einzelfehler – sie sind Systemmängel, die TeamPCP jetzt systematisch ausnutzt.
☁️ Cloud-Infrastruktur
AWS/GCP/Azure-Keys, Kubernetes-Tokens, SSH-Zugang
FBI-Warnung aktiv
🧠 KI-Systeme
OpenAI, Anthropic, Google-API-Keys – Missbrauch & Manipulation möglich
Ungesichert
⚙️ CI/CD-Pipelines
434.000 Pipelines exponiert – Backdoors möglicherweise noch aktiv
Prüfung nötig
🏗️ Entwickler
GitHub-Tokens, Deploy-Keys, persönliche Cloud-Credentials
Sofort rotieren
🏢 Unternehmen (2.500+)
Infrastruktur-Exposition, Compliance-Risiken, Nachfolge-Angriffe
Validierung läuft
👤 Endnutzer / Kunden
Keine direkten Kundendaten im Datensatz – indirektes Risiko bleibt
Kein bekanntes Risiko
Was Entwickler und Teams jetzt sofort tun müssen
Das ist kein theoretisches Risiko. Die FBI-Warnung ist explizit: Handeln ist jetzt erforderlich. Hier sind die konkreten Schritte – geordnet nach Dringlichkeit.
1
Sofort prüfen: War LiteLLM 1.82.7 oder 1.82.8 installiert?
Prüfe alle Systeme, CI-Pipelines und Docker-Images auf die Versionen 1.82.7 und 1.82.8. Auch indirekte Abhängigkeiten zählen: CrewAI, DSPy, Browser-Use, Mem0, Guardrails und Camel-AI haben LiteLLM als transitive Dependency. Snyk bestätigt: 1.82.6 und früher sind sicher.
2
Alle Credentials rotieren – ohne Ausnahme
Wenn eine betroffene Version lief: Alle Credentials behandeln, als wären sie kompromittiert. AWS-Keys, GCP Service Accounts, Azure Service Principals, GitHub-Tokens, PyPI-Credentials, Kubernetes-Tokens, SSH-Keys und sämtliche LLM-API-Keys neu generieren. Ein Versions-Downgrade allein reicht nicht.
3
Persistence-Mechanismen suchen und entfernen
Nach der Datei litellm_init.pth in allen Python-Umgebungen suchen. Auf unerklärliche systemd-Services prüfen, die als legitime System-Prozesse getarnt sind. Kubernetes-Cluster auf unbekannte Pods – insbesondere solche mit dem Namensmuster node-setup-* – untersuchen. Betroffene Systeme neu aufsetzen, nicht nur patchen.
4
Audit-Logs rückwirkend prüfen
AWS CloudTrail, GCP Audit Logs und Azure Activity Logs ab dem 24. März 2026 auf ungewöhnliche Aktivitäten prüfen. Besondere Aufmerksamkeit auf: neue IAM-Rollen oder -Policies, unbekannte API-Aufrufe aus ungewöhnlichen Regionen, Zugriffe auf Secrets Manager oder Vault, und anomale Datenabflüsse.
5
Langfristig: Dependency-Pinning und Package-Signing einführen
Alle Package-Versionen in Requirements-Files explizit pinnen. PyPI Trusted Publishers statt statischer API-Tokens für das Publishing nutzen. Packages mit Checksums validieren. CI/CD-Pipelines auf Anomalien in Dependency-Graphs überwachen. Und: nie einem Security-Tool blind vertrauen – auch Vulnerability-Scanner sind Angriffsvektoren.
Das eigentliche Problem: KI-Infrastruktur als Hochwertziel
Der LiteLLM-Angriff ist kein Zufall und kein Einzelfall. Er ist das logische Ergebnis eines Trends, den Sicherheitsforscher seit Jahren beschreiben: Je mehr Unternehmen KI in ihre Kernprozesse integrieren, desto wertvoller werden die Zugangsdaten zu diesen KI-Systemen. TeamPCP hat verstanden, dass ein einzelner LiteLLM-Angriff nicht ein Unternehmen kompromittiert – sondern potenziell jedes Unternehmen, das irgendeinen modernen KI-Stack betreibt.
Was den LiteLLM-Angriff von früheren Supply-Chain-Angriffen unterscheidet: Er greift nicht Produktionscode an, sondern Infrastruktur-Credentials. Ein gestohlener AWS-Key gibt Angreifern potenziell Zugang zu allem, was in der Cloud liegt – unabhängig davon, welcher Code dort läuft. Und ein gestohlener OpenAI-Key ermöglicht nicht nur kostenlosen API-Zugang, sondern auch die Möglichkeit, KI-Ausgaben in Produktionssystemen unbemerkt zu manipulieren.
Für Unternehmen, die KI heute als Kernstrategie sehen – und das sind 2026 praktisch alle DAX-Konzerne – ist das eine neue Kategorie von Risiko: KI-Infrastruktur-Security. Es reicht nicht mehr, Applikationscode zu sichern. Die komplette Lieferkette der KI-Tools, von den Bibliotheken über die Build-Systeme bis zu den Deployment-Pipelines, muss als Angriffsfläche verstanden und behandelt werden.
📋 TeamPCPs Angriffs-Chronik – LiteLLM war nicht der erste
Feb. 2026
Trivy (Aqua Security) – GitHub Actions Misconfiguration ausgenutzt. PAT-Token gestohlen. Basis für alle folgenden Angriffe.
Mrz. 2026
LiteLLM (BerriAI) – 153 GB gestohlen, 2.500+ Unternehmen exponiert. Größter KI-Supply-Chain-Angriff 2026. CVE-2026-33634.
Mai 2026
Checkmarx KICS Scanner & Telnyx Python SDK – Gleiche Infrastruktur, gleiche Methode. Supply-Chain bleibt aktives Ziel.
Jul. 2026
FBI FLASH-Warnung – Offizielle Bestätigung, dass gestohlene Credentials noch aktiv genutzt werden. Weitere Angriffe erwartet.
🔍 Das Fazit
153 Gigabyte. 2.488 Unternehmen. 434.000 Pipelines. TeamPCP hat mit einem einzigen vergifteten Python-Paket – 40 Minuten auf PyPI – die Zugangsdaten zu einem erheblichen Teil der globalen KI-Infrastruktur gestohlen. Die Namen auf der Opferliste sind kein Zufall: AWS, Samsung, Nvidia, Siemens, Volkswagen, FedEx. Das sind keine kleinen Startups – das sind die Unternehmen, die das KI-Zeitalter bauen. Was dieser Angriff beweist: Sicherheit in KI-getriebenen Umgebungen kann nicht mehr nur auf Applikationsebene gedacht werden. Jede Bibliothek, jeder Scanner, jedes Tool in der Build-Chain ist ein potenzieller Angriffsvektor. Und wer seine Credentials nicht rotiert hat, sitzt möglicherweise noch immer auf einem offenen Fenster – für TeamPCP oder für wen auch immer das nächste kommt.
FAQ – Was du über den LiteLLM-Supply-Chain-Angriff wissen musst
Bin ich betroffen, wenn ich LiteLLM gar nicht direkt nutze?
Ja, möglicherweise. LiteLLM ist eine transitive Abhängigkeit von vielen populären KI-Frameworks – darunter CrewAI, DSPy, Browser-Use, Mem0, Instructor, Guardrails, Agno und Camel-AI. Wer eines dieser Frameworks nutzt und zwischen dem 24. März und dem Entfernen der Pakete ein Update durchgeführt hat, könnte indirekt betroffen sein. Prüfe alle Abhängigkeiten deines Stacks, nicht nur direkte.
Was bedeutet „2.500 Unternehmen betroffen“ konkret?
Die Zahl beschreibt eine rekonstruierte Exposition, keine bestätigten Einbrüche. CloudSEK und Hudson Rock haben den 153-GB-Datensatz analysiert und mit 2.488 Corporate Domains in Verbindung gebracht. Das bedeutet: Diese Unternehmen hatten mit hoher Wahrscheinlichkeit Credentials in Umgebungen, die die manipulierten Pakete ausgeführt haben. Ob diese Credentials tatsächlich gestohlen und missbraucht wurden, muss jedes Unternehmen selbst prüfen.
Wer ist TeamPCP – und werden sie gefasst?
TeamPCP ist eine finanziell motivierte Hackergruppe, von Google als UNC6780 geführt. Sie sind auf Software-Supply-Chain-Angriffe spezialisiert und verknüpfen ihre Aktivitäten mit Ransomware-Affiliate-Programmen. Die gestohlenen Daten werden auf Telegram gehandelt. Über Festnahmen oder offizielle Attribuierungen mit spezifischen Staaten oder Individuen gibt es bislang keine Informationen.
Reicht es, LiteLLM zu deinstallieren oder zu updaten?
Nein. Das Entfernen oder Updaten der Bibliothek behebt nur das zukünftige Risiko. Alle Credentials, die während der Exposition abgegriffen wurden, bleiben gültig bis sie rotiert werden. Außerdem hinterlässt Version 1.82.8 eine .pth-Datei, die weiterhin ausgeführt wird, und möglicherweise eine systemd-Backdoor. Betroffene Systeme müssen vollständig neu aufgesetzt werden, nicht nur gepatcht.
Was macht diesen Angriff anders als SolarWinds oder Log4Shell?
SolarWinds kompromittierte ein Deployment-Tool und ermöglichte Code-Ausführung. Log4Shell war eine Schwachstelle in einer Logging-Bibliothek. LiteLLM ist qualitativ anders: Die Bibliothek berührt aktiv die sensibelsten Credentials in modernen Umgebungen – Cloud-Zugang und KI-API-Keys. Wer LiteLLMs Laufzeitumgebung kompromittiert, hat Zugriff auf die Schlüssel zu AWS, Google Cloud, Azure und jedem genutzten KI-Modell gleichzeitig. Das ist ein neues Level von Supply-Chain-Risiko.
Wie kann ich prüfen, ob mein Unternehmen im Datensatz ist?
Hudson Rock hat ein öffentliches Lookup-Tool für den „LiteLLM Breach“-Datensatz veröffentlicht, das betroffene Unternehmen abfragen können. CloudSEK hat ebenfalls sein Exposure-Dataset öffentlich gemacht. Alternativ sollten IT-Security-Teams die Logs ihrer CI/CD-Pipelines ab dem 24. März 2026 eigenständig analysieren.
LiteLLM Supply Chain Angriff
TeamPCP Hack 2026
KI Infrastruktur Sicherheit
PyPI Schadcode 2026
AWS Credentials gestohlen
CI/CD Pipeline Angriff
Open Source KI Sicherheit
FBI FLASH Warnung 2026
Trivy Kompromittierung
Cybersecurity 2026
061318944180
