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

LiteLLM Supply-Chain-Angriff: Wie Malware in ein zentrales 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 in vielen Agenten-Stacks als Gateway zwischen Modellanbietern sitzt, konnte dadurch heimlich Secrets und Infrastrukturzugänge abgreifen. Der Fall zeigt, wie schnell ein einzelnes Python-Paket zum Risiko für ganze KI-Umgebungen wird und wo KI-Modelle bei der Aufklärung tatsächlich helfen.

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 sitzt in vielen KI-Projekten an einer besonders sensiblen Stelle: als Gateway, das Aufrufe zwischen Modellen von OpenAI, Anthropic oder Google vereinheitlicht. Genau deshalb ist ein kompromittiertes Paket hier gefährlicher als ein gewöhnlicher Bibliotheksfehler. Nach Analysen zum Vorfall wurde ein Maintainer-Konto kompromittiert und so der manipulierte Upload in die Lieferkette geschoben.

Zwei Malware-Varianten in der Analyse

Eine technische Analyse von Kaspersky beschreibt zwei unterschiedliche Methoden in den betroffenen Versionen:

Version 1.82.7: Der Proxy-Pfad als Einstieg

Hier verbarg sich die Malware in der Datei proxy_server.py. Sie wurde erst aktiv, wenn die Proxy-Funktionalität des Pakets importiert wurde. Ein Base64-kodierter Payload entschlüsselte 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, sprang der Schadcode bei jedem Start der Umgebung an. Für betroffene Teams ist genau das der unangenehme Punkt: Schon ein einmal installiertes Paket kann über den normalen Startpfad weiterarbeiten.

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 verfügbare Secrets und Konfigurationen auf dem Host-System. Anschließend verschlüsselte er die Daten mit AES-256-CBC und übertrug sie an externe Command-and-Control-Server.

KI-Einsatz bei der Aufklärung

Interessant ist nicht nur der Angriff selbst, sondern auch die Art der Analyse. In einem auf FutureSearch veröffentlichten Transkript dokumentiert Callum McMahon, wie Claude half, die verdächtigen Dateien schneller einzuordnen. Der erste sinnvolle Schritt war dabei kein Magietrick, sondern saubere Incident-Hygiene: das Paket in einer isolierten Docker-Umgebung herunterzuladen, statt es lokal unkontrolliert auszuführen.

docker run --rm -it python:3.12-slim bash
pip download litellm==1.82.8  # siehe https://osv.dev/vulnerability/PYSEC-2026-56

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 half anschließend dabei, die Logik des Payloads schneller zu entpacken und die Exfiltrations-Mechanik lesbar zu machen. Genau darin liegt der praktische Wert solcher Modelle im Security-Alltag: nicht als autonome Abwehr, sondern als Beschleuniger beim Verstehen von verdächtigem Code und beim Formulieren der nächsten sauberen Reaktionsschritte.

Warum solche Angriffe für Agenten-Projekte besonders teuer sind

LiteLLM sitzt in der Pipeline zahlreicher KI-Agenten-Projekte. Wenn so ein Gateway kompromittiert wird, betrifft das nicht nur ein einzelnes Tool, sondern potenziell den ganzen Stack dahinter: Modellzugänge, Datenbank-Credentials, Cloud-Rollen, interne Services.

Der Vorfall zeigt damit eine unangenehme Wahrheit moderner KI-Entwicklung. Viele Teams bauen schnell, kombinieren APIs, Frameworks und Paket-Ökosysteme, aber die Supply Chain bleibt oft ein stiller Annahmefehler. Ein einziges kompromittiertes Paket kann reichen, um tausende Downstream-Projekte in Mitleidenschaft zu ziehen. Besonders perfide ist hier, dass .pth-Dateien von manchen Security-Workflows leicht übersehen werden.

Empfohlene Sicherheitsmaßnahmen

Wie das LiteLLM-Team auf GitHub bestätigte, 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. Kurz nach dem Vorfall wurde ein Downgrade auf die sichere Version 1.82.6 empfohlen.

Reaktionen bei einer Infektion

Falls eine der betroffenen Versionen installiert war, sollte das System vom Netzwerk isoliert und alle potenziell exponierten Secrets rotiert werden: AWS-Keys, Datenbank-Passwörter, API-Tokens und CI/CD-Zugänge. Dazu kommen ein Audit der Infrastruktur auf ungewöhnliche Aktivitäten und ein Blick auf ausgehenden Traffic, um mögliche Exfiltration zu erkennen.

Prävention für die Zukunft

Für die Zukunft helfen striktes Version-Pinning und Hash-Verifizierung, etwa via --require-hashes in der requirements.txt. Bei kritischen Anwendungen lohnt sich zusätzlich eine private Registry mit signierten Paketen sowie konsequentes SBOM-Tracking aller Abhängigkeiten.

KI als Werkzeug in der Incident Response

Die Dokumentation des Vorfalls zeigt praxisnah, wo KI-Modelle in der Sicherheitsanalyse nützlich werden: beim schnellen Lesen von Schadcode, beim Strukturieren von Verdachtsmomenten und beim Ableiten nächster Schritte in einer isolierten Analyseumgebung.

Ihre Grenzen bleiben aber klar. Ein Modell erkennt keine laufende Kompromittierung von selbst und ersetzt weder Telemetrie noch erfahrene Incident-Responder. Es beschleunigt die Analyse, aber es trägt nicht die Verantwortung für die Entscheidung.

Die eigentliche Lehre für deinen Stack

Der LiteLLM-Angriff zeigt, dass KI-Agenten und ihre Gateway-Bibliotheken längst zu attraktiven Zielen für Angreifer geworden sind. Supply-Chain-Sicherheit über Paket-Manager ist damit keine lästige Compliance-Aufgabe, sondern Teil des eigentlichen Betriebsmodells.

Für Entwickler von Agenten-Stacks heißt das sehr konkret: Nicht nur Modelle, Benchmarks und Frameworks evaluieren, sondern auch Paketquellen, Hashes, Registry-Strategie und Secret-Hygiene. PyPI hat die kompromittierten Versionen schnell entfernt. Für betroffene Teams beginnt die eigentliche Arbeit aber erst danach: prüfen, rotieren, eingrenzen, absichern.