Was im März in LiteLLMs Build-Pipeline geschah

Der Einbruch begann nicht bei LiteLLM selbst. TeamPCP kompromittierte zunächst den Open-Source-Sicherheitsscanner Trivy, indem die Gruppe einen geleakten Automatisierungs-Token ausnutzte und sich so rund 20 Tage lang unbemerkt Zugang zu Trivys eigenem Repository verschaffte. In diesem Zeitfenster pushte die Gruppe per Force-Push bösartigen Code in Trivys Versions-Tags - jene spezifischen Release-Marker, auf die nachgelagerte Projekte verweisen, wenn sie eine Abhängigkeit beziehen.

LiteLLMs Continuous-Integration-Pipeline installierte Trivy, ohne es auf eine feste, verifizierte Version zu pinnen, sodass sie beim nächsten Lauf automatisch die vergiftete Version zog. Diese eine ungepinnte Abhängigkeit war die gesamte Öffnung, die TeamPCP brauchte: Der bösartige Code gelangte in LiteLLMs eigenen Build-Prozess und von dort in zwei veröffentlichte Pakete, LiteLLM Version 1.82.7 und 1.82.8, die auf den Python Package Index hochgeladen wurden.

Die Schutzmaßnahme, der alle vertrauen, und wie sie umgangen wurde

Die meisten Entwickler, die sich vor bösartigen PyPI-Paketen fürchten, verlassen sich auf das Flag --ignore-scripts, das verhindert, dass die Installationsskripte eines Pakets beliebigen Code ausführen. Die Payload von TeamPCP benötigte kein Installationsskript. Sie steckte in einer .pth-Datei, einer Python-Pfadkonfigurationsdatei, die der Interpreter selbst beim Start automatisch ausführt, bei jedem einzelnen Lauf, unabhängig davon, wie das Paket installiert wurde. Genau dieses Detail fehlte in den meisten Schlagzeilen zu diesem Vorfall, und es ist das Detail, das für jedes Entwicklungsteam am wichtigsten ist, das glaubte, --ignore-scripts schütze es vor genau dieser Angriffsklasse.

Sobald sie lief, sammelte die Payload SSH-Schlüssel, Cloud-Zugangsdaten für AWS, Google Cloud und Azure, Kubernetes-Token, den Inhalt von .env-Dateien sowie API-Schlüssel von KI-Anbietern von jeder Maschine, auf der das vergiftete Paket installiert war. Die gestohlenen Daten wurden mit AES-256 verschlüsselt und entweder an eine Typosquatting-Domain gesendet, die wie eine legitime LiteLLM- oder Trivy-Ressource aussehen sollte, oder direkt in Repositories im eigenen GitHub-Konto des Opfers hochgeladen - ein Detail, das die Operation wie normale Entwickleraktivität aussehen ließ, statt einen offensichtlichen Alarm für ausgehenden Datenverkehr auszulösen.

2.500 Unternehmen, acht namentlich genannte in Europa und eine Lücke von fünf Monaten

CloudSEK veröffentlichte seine Analyse am 11. August 2026, fünf Monate nach der Kompromittierung im März, und identifizierte mehr als 2.500 Organisationen sowie rund 434.000 CI/CD-Pipelines als potenziell exponiert - was die Firma als die bislang größte 2026 aufgedeckte KI-Lieferkettenverletzung bezeichnet. Zu den mit hoher Zuversicht genannten Treffern zählen Siemens AG, Siemens Energy, Deutsche Bahn AG, Orange S.A., Vodafone Group Plc, die London Stock Exchange Group, der finnische Energiekonzern Fortum Oyj und der Rückversicherer Munich Re - quer durch die Branchen Fertigung, Telekommunikation, Bahn, Finanzen und Versicherung in mehreren europäischen Rechtsräumen.

CloudSEK stellt ausdrücklich klar, dass das Auftauchen im Datensatz kein automatischer Beweis für einen erfolgreichen Einbruch ist - der Befund bedeutet, dass Zugangsdaten, Domains, Repositories oder Infrastruktur der betreffenden Organisation in den erbeuteten Daten aufgetaucht sind, und jede Organisation muss selbst untersuchen, was tatsächlich entwendet oder missbraucht wurde, falls überhaupt. Unbestritten ist die Lücke von fünf Monaten zwischen dem Einbruch im März und der Offenlegung im August, ein Zeitfenster, in dem jede der genannten Organisationen mit kompromittierten Zugangsdaten weiterarbeiten konnte, ohne öffentliche Warnung, dass die Kompromittierung überhaupt stattgefunden hatte.

Was das für alle bedeutet, die KI-Infrastruktur-Tools betreiben

Die FLASH-Warnung des FBI vom Juli 2026 fügt der Zeitlinie ein unangenehmes Detail hinzu: Die im März erbeuteten Zugangsdaten gelten Monate später weiterhin als aktiv und nutzbar, und die Behörde rechnet damit, dass TeamPCP oder verbundene Akteure sie in künftigen, eigenständigen Einbrüchen einsetzen, statt sie verfallen zu lassen. Für jede Organisation, die im März 2026 LiteLLM-Version 1.82.7 oder 1.82.8 in Produktion oder CI einsetzte, besteht die richtige Reaktion nicht darin, auf eine individuelle Bestätigung von CloudSEK oder LiteLLM zu warten - sondern darin, sämtliche Zugangsdaten, die diese Build-Pipeline berührt haben, als kompromittiert zu behandeln und jetzt zu rotieren, ob fünf Monate zu spät oder nicht.

Die strukturelle Lehre reicht über LiteLLM hinaus. Jede Organisation, die ihrer CI-Pipeline erlaubt, eine Sicherheits-Tooling-Abhängigkeit wie einen Scanner zu beziehen, ohne sie auf eine verifizierte Version zu pinnen, hat dieselbe Öffnung, die TeamPCP hier nutzte, und --ignore-scripts ist nicht der Schutz, für den ihn die meisten Teams gegen eine über eine .pth-Datei ausgelieferte Payload halten. Europäische Sicherheitsverantwortliche, die KI-Infrastruktur-Tools auf derselben Open-Source-Lieferkette betreiben, sollten dies weniger als eine reine LiteLLM-Geschichte betrachten und mehr als eine Vorschau darauf, wie die nächste Kompromittierung von KI-Tools höchstwahrscheinlich erfolgen wird.

Weiterlesen: 141.006 Testläufe, drei echte Einbrüche  |  Micron: 2027 wird enger als 2026