Minute-by-minute Response zum LiteLLM Malware-Angriff: Wie Claude den Supply-Chain-Attack aufklärt

LiteLLM Supply-Chain-Angriff: Wie Malware in die KI-Gateway gelangte

Takeaway: Am 24. März 2026 wurden die LiteLLM-Pakete 1.82.7 und 1.82.8 auf PyPI mit Malware verseucht. Die Bibliothek, die von zahlreichen Agenten-Projekten genutzt wird, spähte heimlich Cloud-Secrets, Datenbank-Konfigurationen und Krypto-Wallets aus. Dieser Vorfall zeigt, wie schnell Supply-Chain-Angriffe KI-Infrastrukturen gefährden und wie KI-Modelle bei der Aufklärung helfen können.

Der Angriff im Zeitraffer

Am 24. März 2026 erschienen laut einer PyPI-Sicherheitswarnung verdächtige Uploads. Die Versionen litellm==1.82.7 und litellm==1.82.8 enthielten Schadcode und wurden innerhalb weniger Stunden wieder entfernt.

LiteLLM dient als zentrale Gateway-Bibliothek für moderne KI-Agenten, um API-Aufrufe zwischen verschiedenen Sprachmodellen (wie OpenAI, Anthropic oder Google) zu übersetzen und eine einheitliche Schnittstelle zu bieten. Ein Angreifer – laut Sicherheitsforschern mutmaßlich die auf Paket-Repositorys spezialisierte Gruppe TeamPCP – nutzte eine Account-Übernahme des Maintainers, um die manipulierten Pakete einzuschleusen.

Zwei Malware-Varianten in der Analyse

Eine technische Analyse von Kaspersky zeigt zwei unterschiedliche Angriffsmethoden in den betroffenen Versionen:

Version 1.82.7: Der Proxy-Trojaner

Hier verbarg sich die Malware in der Datei proxy_server.py. Sie wurde erst ausgeführt, wenn die Proxy-Funktionalität des Pakets importiert wurde. Ein Base64-kodierter Payload dechiffrierte sich beim Import selbst und startete den Angriff.

Version 1.82.8: Persistenz beim Start

In dieser Version lag der Schadcode in einer litellm_init.pth-Datei. Da Python .pth-Dateien beim Start des Interpreters automatisch lädt, erreichte die Malware absolute Persistenz und wurde bei jedem Start der Umgebung aktiv.

Ziele des Schadcodes

Die Auswertung zeigt, dass es die Angreifer auf sensible Infrastrukturdaten abgesehen hatten. Dazu gehörten Cloud-Zugangsdaten für AWS, GCP und Azure, Kubernetes-Konfigurationen sowie Verbindungsdaten für Datenbanken wie MySQL, PostgreSQL und MongoDB. Auch Krypto-Wallets und CI/CD-Tokens von Plattformen wie GitHub oder GitLab standen im Fokus.

Der Payload arbeitete in zwei Stufen: Zunächst sammelte er alle verfügbaren Secrets und Konfigurationen auf dem Host-System. Anschließend verschlüsselte er diese Daten mit AES-256-CBC und übertrug sie an externe Command-and-Control-Server.

KI-Einsatz bei der Aufklärung

Der Entwickler Callum McMahon dokumentiert in einem Transkript (veröffentlicht auf FutureSearch), wie er den Angriff mithilfe von Claude in Echtzeit analysierte. Nachdem erste verdächtige Aktivitäten in LiteLLM aufgefallen waren, schlug das Modell vor, das Paket in einem isolierten Docker-Container herunterzuladen:

docker run --rm -it python:3.12-slim bash
pip download litellm==1.82.8

Kurz darauf erkannte Claude den Base64-kodierten Payload in der .pth-Datei:

### Code-Ausschnitt: litellm_init.pth
import os, subprocess, sys
subprocess.Popen([sys.executable, "-c", 
  "import base64; exec(base64.b64decode('aW1wb3J0IHN1YnByb2Nlc3MKaW1wb3J0IHRlbXBmaWxl...'))"])

Das Modell dekodierte den Payload und identifizierte die Logik der Malware, darunter das Credential-Stealing und die Persistenz-Mechanismen. Abschließend half Claude dabei, den zuständigen Sicherheitskontakt bei PyPI zu ermitteln und eine präzise Warnmeldung zu formulieren, um die Pakete offline zu nehmen.

Warum Supply-Chain-Angriffe auf KI-Projekte zunehmen

LiteLLM sitzt in der Pipeline zahlreicher KI-Agenten-Projekte. Ein kompromittiertes Gateway bedeutet, dass alle darauf aufbauenden Agenten und deren genutzte Secrets potenziell gefährdet sind.

Der Vorfall verdeutlicht die Achillesferse moderner KI-Entwicklung: Die starke Abhängigkeit von Paket-Managern wie PyPI führt zu einem Kaskadeneffekt, bei dem ein einziges kompromittiertes Paket tausende Downstream-Projekte infizieren kann. Zudem wird Malware in .pth-Dateien von einigen gängigen Security-Tools leicht übersehen.

Empfohlene Sicherheitsmaßnahmen

Wie das LiteLLM-Team auf GitHub bestätigt, sollten Entwickler ihre Installationen umgehend prüfen:

# Welche LiteLLM-Version ist installiert?
pip show litellm

Die Versionen 1.82.7 und 1.82.8 gelten als kompromittiert und sollten deinstalliert werden. Das LiteLLM-Team empfahl kurz nach dem Vorfall ein Downgrade auf die sichere Version 1.82.6.

Reaktionen bei einer Infektion

Falls eine der betroffenen Versionen installiert war, ist es ratsam, das System vom Netzwerk zu isolieren und alle potenziell exponierten Secrets (AWS Keys, Datenbank-Passwörter, API-Tokens) zu rotieren. Ein Audit der Infrastruktur auf ungewöhnliche Aktivitäten sowie das Monitoring des Netzwerk-Traffics auf externe Kommunikation helfen, den Schaden einzugrenzen.

Prävention für die Zukunft

Um sich künftig abzusichern, empfehlen Sicherheitsexperten striktes Version Pinning und Hash-Verifizierung (via --require-hashes in der requirements.txt). Für kritische Unternehmensanwendungen bietet sich zudem eine private Registry mit signierten Paketen sowie konsequentes SBOM-Tracking (Software Bill of Materials) für alle Abhängigkeiten an.

KI als Werkzeug im Incident Response

Die Dokumentation des Vorfalls zeigt praxisnah, wie KI-Modelle bei der Sicherheitsanalyse unterstützen können. Zu den Stärken zählen die schnelle Analyse von Schadcode, das Erkennen von Angriffsvektoren und das prozedurale Wissen, etwa zur sicheren Isolation via Docker.

Gleichzeitig gibt es klare Grenzen: KI-Modelle führen keine eigenständige Live-Erkennung durch, sondern finden nur das, wonach gezielt gesucht wird. Sie können zudem falsche Sicherheit vermitteln, weshalb die finale Bewertung und Entscheidung immer bei menschlichen Sicherheitsexperten liegen muss.

Fazit

Der LiteLLM-Angriff unterstreicht, dass KI-Agenten und ihre Gateway-Bibliotheken zu hochwertigen Zielen für Angreifer geworden sind. Supply-Chain-Sicherheit über Paket-Manager ist keine Nebensache, sondern eine kritische Infrastrukturaufgabe. Gleichzeitig zeigt der Fall, dass eine transparente Dokumentation und schnelle Reaktionen der Community – unterstützt durch KI-Analysen – den Schaden wirksam begrenzen können. Auch wenn PyPI die kompromittierten Versionen zügig entfernt hat, bleibt die Überprüfung bestehender Stacks ein essenzieller Schritt für alle Entwickler von KI-Agenten.