Der LiteLLM-Supply-Chain-Angriff ist ein Weckruf für jedes Team, das KI-Tools einsetzt

Was passiert ist

Am 24. März 2026 veröffentlichte jemand schadhafte Versionen von LiteLLM (1.82.7 und 1.82.8) direkt auf PyPI – unter Umgehung des regulären Release-Prozesses des Projekts. Die kompromittierten Pakete enthielten einen Credential-Stealer, der SSH-Schlüssel, Cloud-Anbieter-Zugangsdaten, Kubernetes-Konfigurationen, API-Schlüssel und mehr abgriff und anschließend an eine Domain exfiltrierte, die wie eine offizielle LiteLLM-Domain aussah, es aber nicht war.

Die schadhaften Pakete waren etwa 40 Minuten lang aktiv, bevor PyPI sie unter Quarantäne stellte. Das klingt nach wenig. Doch LiteLLM wird rund 15–20 Millionen Mal pro Woche installiert, was etwa 1.700 Installationen pro Minute entspricht. In diesem Zeitfenster erfolgten über 119.000 Downloads. Schätzungsweise 40–50 % davon waren ungepinnte Installationen, die automatisch die neueste Version bezogen.

Der Angriff ging von einer kompromittierten Trivy-Abhängigkeit im CI/CD-Security-Scanning-Workflow von LiteLLM aus. Eine Gruppe namens TeamPCP gilt als verantwortlich; es gibt Hinweise darauf, dass sie mit der Erpressergruppe Lapsus$ zusammenarbeitet, um gestohlene Daten zu monetarisieren. Auf der RSA Conference vergangene Woche bestätigten Incident-Response-Forscher Kenntnis von über 1.000 betroffenen SaaS-Umgebungen; Threat Hunter schätzen, dass Daten von 500.000 Maschinen exfiltriert wurden.

Diese Woche meldete sich das erste nachgelagerte Opfer öffentlich zu Wort. Ein KI-Recruiting-Startup bestätigte, „eines von tausenden betroffenen Unternehmen" zu sein, und die Lapsus$-Gruppe versteigert nun, was sie als 4 TB gestohlene Daten bezeichnet – darunter Quellcode, Zugangsdaten und VPN-Konfigurationen.

Warum dieser Angriff mehr zählt als die übliche CVE

Wir sehen so häufig Supply-Chain-Warnmeldungen, dass sie zu verschwimmen beginnen. Dieser Fall ist aus mehreren Gründen anders.

Erstens: der Angriffsvektor. Die Kompromittierung begann nicht bei LiteLLM selbst, sondern bei Trivy, einem Open-Source-Schwachstellenscanner, den viele Teams in ihren CI/CD-Pipelines einsetzen. Man nehme sich einen Moment, um das zu verinnerlichen: Das Tool, das Sie zur Schwachstellensuche verwenden, war der Einstiegspunkt. Ihre Sicherheitswerkzeuge haben Ihre Sicherheit kompromittiert. Das ist nicht nur ironisch – es ist eine Erinnerung daran, dass CI/CD-Pipelines ein hochwertiges Ziel sind und jedes darin ausgeführte Tool dieselbe Prüfung erfordert wie produktive Abhängigkeiten.

Zweitens: die Position von LiteLLM im Stack. Es handelt sich um ein einheitliches Interface für den Aufruf von LLMs verschiedener Anbieter. Das bedeutet, es hat typischerweise Zugriff auf API-Schlüssel für jeden von Ihnen genutzten KI-Anbieter sowie auf alle Umgebungsvariablen und Cloud-Zugangsdaten im selben Kontext. Ein Paket in dieser Position zu kompromittieren gibt Angreifern einen Kurzschluss zu allem.

Drittens: der nachgelagerte Schadensradius. LiteLLM wird nicht nur direkt installiert. Es ist eine transitive Abhängigkeit, die von KI-Agent-Frameworks, MCP-Servern und LLM-Orchestrierungstools eingebunden wird. Teams, denen LiteLLM kein Begriff ist, haben es möglicherweise trotzdem in ihren CI-Jobs ausgeführt.

Was wir in unserer eigenen Arbeit immer wieder sehen

Bei Penetrationstests für Gaming-Studios gehört die CI/CD-Pipeline zu den ersten Dingen, die wir untersuchen. Sie ist konsequent das schwächste Glied. Teams investieren viel in Firewalls, WAFs und Laufzeit-Monitoring, doch die Build-Pipeline läuft oft mit übermäßig weiten Berechtigungen, zieht Abhängigkeiten ohne Versionspinning und protokolliert Secrets auf eine Weise, die einem den Magen umdreht.

Ähnliche Muster haben wir beim Aufbau cloudnativer Anwendungen für Enterprise-Kunden mit strengen Compliance-Anforderungen beobachtet. Schweizer Regulierungsumgebungen etwa verlangen, dass Sie die Kontrolle über Ihre Software-Lieferkette nachweisen können. Das ist keine bloße Checkbox-Übung. Es bedeutet, genau zu wissen, welche Version jeder Abhängigkeit Sie ausführen, wann sie veröffentlicht wurde und welche Prüfsummen übereinstimmen. Die Teams, die diese Disziplin bereits etabliert hatten, waren von diesem Angriff am wenigsten betroffen.

In unseren nativen iOS- und Android-Projekten waren wir historisch etwas besser gegen diese Art von Angriffen abgeschirmt, weil die Apple- und Google-Ökosysteme zentralisiertere Build-Toolchains haben. Doch das Muster verschiebt sich. Immer mehr Mobile-Teams integrieren KI-Codegenerierungstools und LLM-basierte Funktionen in ihre Apps, wodurch Python-basierte Tools in Build-Pipelines einziehen, die das bisher nie hatten. Wenn Sie KI/ML-Vorverarbeitung als Teil Ihres Mobile-Builds ausführen, prüfen Sie Ihren Abhängigkeitsbaum.

Was Sie konkret tun sollten

Hier sind konkrete Schritte. Einige davon können Sie noch heute umsetzen.

Pinnen Sie Ihre Abhängigkeiten. Nicht nur in der requirements.txt, sondern überall: in Dockerfiles, CI-Konfigurationen, GitHub Actions. Verwenden Sie Hash-Pinning, wo Ihr Paketmanager es unterstützt. Die Tatsache, dass 40–50 % der LiteLLM-Installationen bei jedem Durchlauf die neueste Version holten, ist die eigentliche Ursache dafür, dass ein 40-minütiges Fenster so viele Umgebungen betroffen hat.

Prüfen Sie, ob Sie betroffen waren. Wenn Sie LiteLLM via pip am 24. März zwischen 10:39 und 16:00 UTC installiert oder aktualisiert haben, prüfen Sie auf die Versionen 1.82.7 oder 1.82.8. Führen Sie pip show litellm in jeder Umgebung aus. Suchen Sie nach ~/.config/sysmon/sysmon.py und verdächtigen Pods in Kubernetes, die node-setup-* entsprechen. LiteLLM und mehrere Sicherheitsfirmen haben Scanner-Skripte veröffentlicht. Nutzen Sie diese.

Rotieren Sie Zugangsdaten konsequent. Wenn Sie ein Anzeichen einer Kompromittierung finden, gehen Sie davon aus, dass jedes Credential auf dieser Maschine verbrannt ist: SSH-Schlüssel, Cloud-Tokens, Datenbankpasswörter, API-Schlüssel in .env-Dateien. Das bloße Entfernen des Pakets reicht nicht aus, da die Malware darauf ausgelegt war, Persistenz herzustellen und möglicherweise bereits zusätzliche Payloads deployiert hat.

Nutzen Sie Dependency-Cooldowns. PyPI führt „Relative Dependency Cooldowns" in pip v26.1 ein (voraussichtlich diesen Monat), mit denen Sie pip so konfigurieren können, dass nur Pakete installiert werden, die seit einem Mindestzeitraum veröffentlicht sind. Das schützt nicht vor allem, hätte aber die automatische Installation eines Pakets verhindert, das 40 Minuten lang aktiv war. Absolute Cooldowns können Sie bereits in pip v26.0 mit dem Flag --uploaded-prior-to setzen.

Auditieren Sie die Berechtigungen Ihrer CI/CD-Tools. Ihr Schwachstellenscanner, Ihr Linter, Ihr Test-Runner – sie alle laufen mit den Berechtigungen, die Ihre Pipeline besitzt. Wenn Ihre Pipeline in die Produktion pushen kann, kann das auch ein kompromittierter Scanner. Wenden Sie das Least-Privilege-Prinzip auf jeden Schritt an.

Die unbequeme Wahrheit über KI-Tooling und Lieferketten

Hier ist, was mich bei diesem Fall nicht loslässt. Der KI-Entwicklungsstack ist jung, bewegt sich schnell und wird von einer verhältnismäßig kleinen Anzahl an Open-Source-Paketen zusammengehalten, von denen alle abhängig sind: LiteLLM, LangChain, verschiedene Agent-Frameworks. Diese Projekte entwickeln sich schnell, veröffentlichen häufig und werden von kleinen Teams gepflegt. Das ist keine Kritik – das ist schlicht die Realität, in der wir uns befinden.

Der 2026 State of DevOps Modernization Report fand heraus, dass fast ein Viertel aller Deployments eine Nachbesserung erfordert, wobei die Behebungszeiten im Schnitt über 7,5 Stunden liegen. Fügt man KI-generierten Code und KI-verwaltete Abhängigkeiten hinzu, entsteht eine Lieferkette, die sich schneller ausweitet, als die meisten Teams sie auditieren können.

Aus unserer PHP- und Docker-Arbeit mit Enterprise-Kunden wissen wir: Lieferkettendisziplin ist langweilig. Sie ist unspektakulär. Niemand möchte einen Sprint damit verbringen, Dependency-Pins zu verschärfen und CI-Berechtigungen zu prüfen. Aber die Teams, die es tun, schlafen durch Vorfälle wie diesen hindurch, anstatt hektisch jedes Credential zu rotieren, das sie besitzen.

Wenn sich das alles unangenehm vertraut anhört – oder wenn Sie nicht sicher sind, ob Ihre CI/CD-Pipeline einem solchen Angriff standhalten würde – sprechen Sie uns an. Wir führen Sicherheitsüberprüfungen durch, die explizit Build-Pipelines und Abhängigkeitsmanagement abdecken, nicht nur den Produktionsperimeter, und wir bringen die Entwicklungserfahrung mit, um zu verstehen, was für Ihr Team tatsächlich praktisch umsetzbar ist.