Wenn Sicherheitsscanner zur Waffe werden: Eine Aufschlüsselung des LiteLLM-Angriffs auf die Lieferkette

LiteLLM ist eine beliebte Open-Source-Python-Bibliothek und ein Proxy-Server, der eine einheitliche Schnittstelle für den Aufruf von mehr als 100 Large Language Model (LLM)-APIs wie OpenAI, Anthropic, Bedrock und VertexAI bietet, wobei das standardmäßige OpenAI-Eingabe-/Ausgabeformat verwendet wird. Es vereinfacht die Integration mehrerer LLMs und bietet Funktionen wie automatische Fallbacks, Wiederholungsversuche und Kostenverfolgung. Da es als API-Gateway fungiert, fungiert es von vornherein als Credential Aggregator, der API-Schlüssel für verschiedene LLM-Anbieter sicher verwahrt.

Überblick

LiteLLM wird in großem Umfang von Unternehmen wie Stripe, Netflix und Google ADK eingesetzt. Darüber hinaus wird LiteLLM monatlich über 95 Millionen Mal heruntergeladen und ist als transitive Abhängigkeit in wichtigen KI-Agenten-Frameworks wie CrewAI, DSPy, Opik, Browser-Use, MLflow und OpenHands weit verbreitet.

Eine finanziell motivierte Gruppe von Bedrohungsakteuren mit dem Namen TeamPCP (auch als DeadCatx3, PCPcat, ShellForce und CipherForce bekannt) führte einen kritischen Angriff auf die Software-Lieferkette des offiziellen Pakets `litellm` im Python Package Index (PyPI) durch. TeamPCP, das Berichten zufolge mit der Erpressergruppe LAPSUS$ zusammenarbeitet, hatte es auf die PyPI-Veröffentlichungsdaten von Krrish Dholakia, dem CEO und Hauptverantwortlichen für LiteLLM, abgesehen.

Wer und was war betroffen?

Die Angreifer veröffentlichten zwei bösartige, gefälschte Versionen (1.82.7 und 1.82.8) direkt auf PyPI und umgingen so den offiziellen CI/CD-Veröffentlichungsprozess von GitHub:

• Version 1.82.7 enthielt eine eingeschleuste base64-kodierte Nutzlast in `litellm/proxy/proxy_server.py`, die böswillig ausgeführt wurde, sobald das Modul importiert wurde.

• Version 1.82.8 enthielt eine hochgefährliche `litellm_init.pth` Datei, die im Wurzelverzeichnis des Rades abgelegt war. Die nativen Pfadkonfigurationsfunktionen von Python verarbeiten `.pth`-Dateien automatisch beim Start des Interpreters. Dies bedeutete, dass die Malware jedes Mal im Hintergrund lief, wenn ein Python-Prozess gestartet wurde, unabhängig davon, ob der Benutzer LiteLLM explizit importiert hatte.

Jedes Unternehmen, jeder Entwickler, jede CI/CD-Pipeline und jeder Docker-Build-Prozess, der/die am 24. März 2026 zwischen 10:39 UTC und ca. 16:00 UTC `pip install litellm` ausgeführt hat (oder es als nicht angeheftete transitive Abhängigkeit gezogen hat), ist betroffen.

Wer NICHT betroffen ist: Benutzer des offiziellen LiteLLM Proxy Docker-Images (`ghcr.io/berriai/litellm`) und der LiteLLM Cloud waren nicht betroffen, da ihre Abhängigkeiten strikt auf sichere Versionen gepinnt waren.

Die Malware führte einen verheerenden dreistufigen Angriff aus:

• Systematic Credential Harvesting: Sie durchsuchte die betroffenen Systeme und sammelte LLM-API-Schlüssel, SSH-Schlüssel, AWS/GCP/Azure-Cloud-Anmeldedaten, Kubernetes-Service-Kontotoken, Docker-Registry-Authentifizierungstoken, Datenbankverbindungszeichenfolgen, Git-Anmeldedaten, Shell-Historien, CI/CD-Geheimnisse und Kryptowährungs-Geldbörsen.

• Exfiltration: Die gestohlenen Daten wurden in einem Archiv (`tpcp.tar.gz`) gebündelt, mit einem hybriden AES-256- und RSA-4096-Schema verschlüsselt und unbemerkt an die vom Angreifer kontrollierte `models.litellm[.]cloud` gesendet.

• Seitliche Verschiebung und Persistenz: In Kubernetes-Clustern verwendete der Angreifer Token für zugängliche Dienstkonten, um alle Cluster-Geheimnisse auszulesen und einen hochprivilegierten `alpine:latest`-Pod (`node-setup-*`) auf jedem Knoten zu installieren. Anschließend installierte er eine dauerhafte System-Backdoor (`sysmon.py` und `sysmon.service`), die regelmäßig `checkmarx[.]zone/raw` abfragte, um beliebige Nutzdaten der zweiten Stufe von den Angreifern herunterzuladen und auszuführen.

Zeitleiste der Ereignisse

• Ende Februar 2026: Ein autonomer KI-Bot namens "hackerbot-claw" nutzt einen falsch konfigurierten Pull-Request-Workflow im Trivy-Repository von Aqua Security aus und stiehlt ein privilegiertes GitHub-Token.

• 19. März 2026: TeamPCP nutzte den verbleibenden Zugang aus dem Trivy-Verletzungsfall, um eine Trivy-Binärdatei mit gestohlenen Zugangsdaten und vergifteten GitHub-Aktionen zu verbreiten. Da LiteLLM Trivy in seinem eigenen CI/CD-Sicherheits-Scanning-Workflow verwendete, ohne die Version zu pinnen, konnte der kompromittierte Trivy-Scanner unbemerkt LiteLLMs `PYPI_PUBLISH`-Token abgreifen.

• 20. bis 23. März 2026: Die Bedrohungsakteure setzten einen sich selbst verbreitenden Wurm ("CanisterWorm") im npm-Ökosystem ein und kompromittierten Checkmarx KICS GitHub-Aktionen. Außerdem registrierten sie eine bösartige Exfiltrationsdomäne, "models.litellm[.]cloud", um eine legitime LiteLLM-Infrastruktur und eine C2-Domäne "checkmarx[.]zone" zu imitieren.

• 24. März 2026, 10:39 UTC: TeamPCP hat das gestohlene PyPI-Token verwendet, um die bösartige Version 1.82.7 von `litellm` in PyPI zu veröffentlichen.

• 24. März 2026, 10:52 UTC: Die Angreifer weiteten den Angriff aus, indem sie die Version 1.82.8 veröffentlichten, die den aggressiven `.pth`-Dateiausführungsvektor hinzufügte.

• 24. März 2026, 11:48 UTC: Sicherheitsforscher von FutureSearch entdeckten die Kompromittierung, nachdem der "pth"-Übertragungsmechanismus der Malware versehentlich eine exponentielle "Fork-Bombe" erzeugt hatte, die ihr System zum Absturz brachte.

• 24. März 2026, 12:44 UTC: Die Angreifer setzten ein Botnet ein, um die GitHub-Enthüllung zu spammen und benutzten kompromittierte Maintainer-Konten, um Repositories vorübergehend zu verunstalten und die Enthüllung als "nicht geplant" zu schließen, um die Reaktion auf den Vorfall zu stören.

• 24. März 2026, 13:38 UTC: Das PyPI-Sicherheitsteam hat das gesamte `litellm`-Projekt erfolgreich unter Quarantäne gestellt und weitere Downloads blockiert.

• 24. März 2026, 15:27 UTC: Die bösartigen Versionen wurden dauerhaft gelöscht, die Konten der Betreuer wurden wiederhergestellt, und alle Schlüssel wurden erfolgreich rotiert.

EmpfohleneAbhilfemaßnahmen

Wenn Sie vermuten, dass Ihr System, Ihre CI/CD-Pipeline oder Ihr Docker-Image mit `litellm` 1.82.7 oder 1.82.8 in Berührung gekommen ist, müssen Sie sofort die folgenden Abhilfemaßnahmen ergreifen:

• Identifizieren Sie die Gefährdung: Überprüfen Sie alle Python-Umgebungen, um festzustellen, ob die Versionen 1.82.7 oder 1.82.8 derzeit installiert sind (`pip show litellm | grep Version`), und suchen Sie explizit nach dem Vorhandensein der Datei `litellm_init.pth` in `site-packages`.

• Vollständige Kompromittierung annehmen und Geheimnisse rotieren: Wenn eine der beiden Versionen vorhanden war, müssen Sie davon ausgehen, dass alle Anmeldeinformationen, Cloud-Tokens, Datenbankpasswörter, LLM-Schlüssel und SSH-Schlüssel, die für die Umgebung zugänglich sind, gestohlen wurden. Rotieren Sie sofort alle Anmeldeinformationen.

• Beseitigen Sie die Persistenz: Stoppen und deaktivieren Sie die systemd-Einheit `sysmon.service` und löschen Sie `~/.config/sysmon/sysmon.py`, `/tmp/pglog` und `/tmp/.pg_state`. Überprüfen Sie in Kubernetes-Umgebungen gründlich den Namensraum "kube-system" und löschen Sie alle Angreifer-Pods, die "node-setup-*" entsprechen.

• Bereinigen Sie Umgebungen und bauen Sie sie neu auf: Führen Sie nicht einfach ein Downgrade des Pakets durch. Löschen Sie die virtuellen Python-Umgebungen vollständig und erstellen Sie sie neu. Bereinigen Sie lokale Paketmanager-Caches (`pip cache purge` oder `rm -rf ~/.cache/uv`), um die versehentliche Neuinstallation von zwischengespeicherten bösartigen Rädern zu verhindern. Bauen Sie betroffene CI-Umgebungen aus sauberen Basis-Images neu auf.

• Pin-Abhängigkeiten: Stellen Sie sicher, dass Ihre Umgebungen auf die letzte bekannte saubere Version gepinnt sind (`litellm==1.82.6` oder früher).

• Blockieren Sie bösartige Infrastrukturen: Blockieren Sie ausgehende Netzwerkverbindungen und DNS-Auflösungen für die bekannten IOCs an Ihrem Netzwerkrand.

Anzeichen für eine Gefährdung (IOCs)

Wenn Sie sich über eine der in diesem Bulletin beschriebenen Bedrohungen Sorgen machen oder Hilfe benötigen, um herauszufinden, welche Schritte Sie unternehmen sollten, um sich vor den größten Bedrohungen für Ihr Unternehmen zu schützen, wenden Sie sich bitte an Ihren Kundenbetreuer oder nehmen Sie Kontakt mit uns auf, um zu erfahren, wie Sie Ihr Unternehmen schützen können.