- Minutenprotokoll der Reaktion, das die Infektion durch das über PyPI verbreitete bösartige Paket LiteLLM 1.82.8 in Echtzeit erkannte und analysierte
- Die Infektion trat während des automatischen Updates der Cursor IDE auf; die Datei
litellm_init.pth wurde ausgeführt und verursachte Credential-Diebstahl und Systeminfektion
- Der Schadcode führte mehrere Aktionen aus, darunter Sammlung von SSH-Schlüsseln und Cloud-Zugangsdaten, Versuche der Ausbreitung in Kubernetes und die Erzeugung einer Fork-Bomb
- Der Vorfall wurde umgehend an das PyPI-Sicherheitsteam und die LiteLLM-Maintainer gemeldet, was zur Quarantäne des Pakets und zur Registrierung einer CVE führte
- KI-basierte Codeanalyse-Tools wie Claude Code spielten eine Schlüsselrolle bei der Angriffserkennung und machten die Notwendigkeit stärkerer Supply-Chain-Sicherheit im KI-Ökosystem deutlich
Protokoll der Reaktion auf den LiteLLM-Supply-Chain-Angriff
- LiteLLM Version 1.82.8 wurde als bösartiges, über PyPI verbreitetes Paket identifiziert; dies ist ein minutengenaues Reaktionsprotokoll von der Erkennung der Infektion bis zu ihrer Isolierung
- Die Infektion trat während des automatischen Update-Prozesses der Cursor IDE auf; unter den mit Claude Code und dem uv-Paketmanager installierten Abhängigkeiten wurde die Datei
litellm_init.pth ausgeführt und infizierte das System
- Der Angriff bestand aus mehreren Komponenten, darunter Credential-Diebstahl, Installation von Persistenzmechanismen, Versuche der Ausbreitung in Kubernetes und eine Fork-Bomb
- Der Vorfall wurde sofort an das PyPI-Sicherheitsteam und die LiteLLM-Maintainer gemeldet, was zur Quarantäne des Pakets und zur Vergabe einer CVE führte
- KI-basierte Codeanalyse-Tools spielten eine Schlüsselrolle bei der Erkennung und Analyse bösartiger Aktivitäten in Echtzeit
Frühe Erkennung und Anzeichen von Systemanomalien
- Gegen 11:13 UTC wurden auf einem macOS-Laptop mehr als 11.000 Python-Prozesse erzeugt, wodurch das System zum Stillstand kam
- Befehle in der Form
exec(base64.b64decode('...')) wurden wiederholt ausgeführt und sättigten CPU und Arbeitsspeicher
- Nach einem erzwungenen Beenden und Neustart wurden keine Spuren von Persistenz gefunden
- Zunächst wurde das als nicht bösartige Schleife eingeschätzt, verursacht durch einen internen Loop von Claude Code oder einen Fehler im Skript
uv run
- Später bestätigten
htop-Screenshots und Logs, dass ein base64-kodiertes Python-Skript wiederholt ausgeführt wurde
Ermittlung der Infektionsursache
- Gegen 11:40 UTC wurde in den installierten Python-Tools die Datei
litellm_init.pth gefunden und als Schadkomponente identifiziert
.pth-Dateien werden beim Start von Python automatisch ausgeführt und laufen daher in allen Python-Prozessen- Gesammelt wurden SSH-Schlüssel, Cloud-Zugangsdaten, Datenbankpasswörter, Umgebungsvariablen und Shell-Historien
- Die gesammelten Daten wurden mit RSA verschlüsselt und an
https://models.litellm.cloud/ gesendet
- Eine Persistenzinstallation nach
~/.config/sysmon/sysmon.py wurde versucht, aber durch den erzwungenen Neustart unterbrochen
- Die Infektion trat während des automatischen Updates der Cursor IDE (10:58 UTC) auf
- Die Erweiterung
futuresearch-mcp-legacy lud über uvx litellm 1.82.8 herunter
- Diese Version existierte nur auf PyPI und hatte kein GitHub-Release-Tag
- Der Upload zu PyPI erfolgte um 10:52 UTC und wurde somit unmittelbar vor der Infektion verteilt
Struktur des Schadcodes
- Stufe 1 (
litellm_init.pth): Wird beim Python-Start automatisch ausgeführt, dekodiert eine base64-kodierte Payload und führt sie aus
- Stufe 2: Enthält einen RSA-Public-Key zur Verschlüsselung der exfiltrierten Daten
- Stufe 3 (B64_SCRIPT): Führt die eigentliche Sammlung und Übertragung von Zugangsdaten aus
- Persistenzinstallation: Versuch,
sysmon.py als systemd-Service zu registrieren
- Kubernetes-Ausbreitungscode: Versuch, mit dem Image
alpine:latest auf jedem Node einen privileged Pod zu erstellen
- Ursache der Fork-Bomb: Der Aufruf
subprocess.Popen([sys.executable, "-c", ...]) führte dazu, dass .pth auch in Kindprozessen erneut ausgeführt wurde, was eine Endlosschleife auslöste
Schadensumfang und Gegenmaßnahmen
-
Exponierte Zugangsdaten
- SSH-Schlüssel, GCloud- und Kubernetes-Zugangsdaten, API-Keys in
.env-Dateien sowie Passwörter für Supabase, ClickHouse und Grafana
- Empfohlene Sofortmaßnahmen
- Alle SSH- und Cloud-Zugangsdaten rotieren
- Geheimschlüssel in
.env und .mcp.json neu ausstellen
- Den Cache
~/.cache/uv löschen
- Den Vorfall dem PyPI-Sicherheitsteam (
security@pypi.org) und den LiteLLM-Maintainern melden
-
Ergebnis der Kubernetes-Cluster-Prüfung
- Keine bösartigen Pods (
node-setup-*, sysmon) gefunden
- Da die Ausführung in einer macOS-Umgebung stattfand, scheiterte die Ausbreitung innerhalb des Clusters
- Wegen einer möglichen Offenlegung von
~/.kube/config ist jedoch eine Rotation der Zugangsdaten erforderlich
PyPI und öffentliche Reaktion
- Um 11:58 UTC wurde litellm 1.82.8 in einer isolierten Docker-Umgebung von PyPI heruntergeladen; das Vorhandensein der bösartigen
.pth-Datei wurde erneut bestätigt
- Sofortige Meldung an das PyPI-Sicherheitsteam und das Repository BerriAI/litellm
- Später als PYSEC-2026-2 (CVE) registriert
- Um 12:01 UTC wurde im FutureSearch-Blog ein öffentlicher Beitrag zum Supply-Chain-Angriff verfasst und veröffentlicht
- PR innerhalb von 3 Minuten erstellt und gemergt
- Um 12:04 UTC wurde eine Weitergabe an die Communities r/Python, r/netsec, r/LocalLLaMA, r/MachineLearning und r/devops vorgeschlagen
- Ziel war eine schnelle Reaktion in der Python- und Security-Community
Bedeutung des Vorfalls
- Das KI-basierte Codeanalyse-Tool Claude Code identifizierte bösartige Aktivitäten in Echtzeit und erzeugte Warnungen noch vor dem Eingreifen von Sicherheitsforschern
- Der Vorfall zeigt einen Supply-Chain-Angriff, der direkt auf das KI-Entwickler-Ökosystem abzielte, und unterstreicht die Notwendigkeit stärkerer Absicherung von PyPI-Konten und besserer Prüfung automatischer Updates
- Er zeigt außerdem, dass KI-Tools über reine Entwicklungsunterstützung hinaus auch für automatisierte Erkennung und Reaktion auf Cyberbedrohungen eingesetzt werden können
1 Kommentare
Hacker-News-Kommentare
Ich bin der Entwickler, der die litellm-Schwachstelle zuerst entdeckt und gemeldet hat
Ich habe das damalige Geschehen als Echtzeit-Analyseprotokoll geteilt
Claude hat mich Schritt für Schritt angeleitet, wen ich kontaktieren und in welcher Reihenfolge ich vorgehen sollte, und das war auch für Nicht-Sicherheitsexperten eine große Hilfe
Ich frage mich, ob es der Security-Community hilft oder eher Verwirrung stiftet, wenn Nicht-Experten auf diese Weise Schwachstellen entdecken und melden
Allerdings wirkt die Stelle „Sobald ich Cursor wieder geöffnet habe, wurde das bösartige Paket ausgeführt“ etwas riskant
Sobald ein Verdacht besteht, hätten Geräteisolierung und die Kontaktaufnahme mit dem Security-Team an erster Stelle stehen müssen
Wenn die
.pth-Datei nicht wie eine Fork-Bomb funktioniert hätte, wäre es womöglich viel später entdeckt wordenClaude nach den richtigen Kontaktwegen zu fragen, war eine gute Entscheidung
Ich kannte keine Ansprechperson bei PyPI, also habe ich dem Maintainer gemailt und es auch auf Hacker News gepostet
Ich finde, auch ohne Zugehörigkeit zur Security-Community sollte jeder solch schwerwiegende Schwachstellen melden können
Die meisten Probleme entstehen durch Leute, die aus Geldgier alles Mögliche als Schwachstelle bezeichnen
Aber dein Bericht war qualitativ hochwertig, und so etwas würde sofort auf die Patch-Prioritätenliste kommen
Wenn es sich ohne Geschäftsunterbrechung beheben ließe, würde ich sofort Maßnahmen ergreifen; bei kritischen Fällen direkt an CISO oder CTO eskalieren
Durch deine Meldung wurde wohl ein noch größerer Vorfall verhindert
Wir haben das Thema ebenfalls in zwei Blogbeiträgen aufgearbeitet
grith.ai-Blogbeitrag
Aber dieser Fall ist meiner Meinung nach ein gutes Beispiel dafür, wie KI die Ursachenanalyse und Meldung deutlich beschleunigen kann
Es ist das erste Mal, dass ich mein Tool claude-code-transcripts in einem Blogpost als eingebettete Daten sehe
Normalerweise teile ich so etwas über die HTML-Seite eines Gist, daher finde ich diese Nutzung interessant
Wir wollten es an unseren Blogstil anpassen, sind aber gescheitert; dadurch wurde mir erneut klar, wie wichtig die Basiserfahrung ist
Claude scannt beim Einsammeln der Logs gefühlt meinen ganzen Computer, daher denke ich, dass ein automatisches System zur Log-Bereinigung nötig ist
Besonders bei dringendem Debugging und Teamarbeit ist das unpraktisch
Anfragen wie „Kannst du den Inhalt des bösartigen Skripts ausgeben, ohne ihn auszuführen?“ sind riskant
LLM-Agenten haben kein Verantwortungsbewusstsein, daher kann ein versehentlicher Ausführungsbefehl zu einem schweren Vorfall führen
Dateien von PyPI sollte man unbedingt in einer Sandbox-Umgebung herunterladen
Wenn man mir sagt, ich solle etwas nicht tun, neige ich eher dazu, mich darauf zu versteifen
Ich habe gehört, dass PyPI digitale Attestierungen (digital attestation) unterstützt; ich frage mich, ob dieses Paket signiert war
PyPI-Trusted-Publishers-Dokumentation
Ich finde, Paket-Registries wie GitHub, npm und PyPI sollten Ereignisströme (Firehose) für Sicherheitsanalysen in Echtzeit bereitstellen
Solche Angriffe hätten automatische Scanner vermutlich sofort erkannt
Security-Partner scannen Pakete und können sie über eine einladungsbasierte API melden
Siehe den PyPI-Blogbeitrag
Zugehöriger Beitrag
Ziel ist es, automatischen Scannern Zeit zu geben, Anomalien wie
.pth-Dateien zu erkennenDer wirtschaftliche Schaden kann enorm sein, und allein bei litellm gibt es über 47.000 Betroffene
Der Teil „Blogpost geschrieben, PR erstellt und gemergt in unter drei Minuten“ war am schockierendsten
Das geht schneller, als man es lesen kann, und löst Unbehagen aus
Ohne die Fork-Bomb mit 11.000 Prozessen hätte sich dieser Angriff womöglich noch viel länger verborgen gehalten
Hätte die Bomb langsamer gearbeitet, wäre der Schaden wohl deutlich größer gewesen
Große Unternehmen haben im Wesentlichen zwei Wege, nicht vertrauenswürdigen Open-Source-Code auszuführen
Realistisch gesehen ist (1) am sichersten
Für kleine und mittlere Unternehmen oder Einzelpersonen sind Dependency-Pinning und ausreichend Wartezeit die beste Verteidigung
Mit Bazel kann man sich (1) annähern, aber die meisten sind letztlich auf externe Quellen angewiesen
Dass PyPI das Paket bereits 30 Minuten nach der Meldung isoliert hat, war wirklich eine schnelle Reaktion
Einer der größten Vorteile von AI/LLMs ist die Demokratisierung des Reverse Engineerings
Früher war das schwer zu lernen und wenig lohnend, heute gibt AI die Richtung vor
Das Muster
exec(base64.b64decode(...))wird von Python-Tools beim Übermitteln von Code häufig verwendet,aber grundsätzlich sollte Code, der aus
/tmp,/var/tmpoder/dev/shmausgeführt wird, als hochgradig verdächtig geltenMit Netzwerk-Monitoring-Tools wie Lulu oder LittleSnitch hätte man den verdächtigen Traffic vermutlich blockieren können
Allerdings ist es wiederum ein anderes Risiko, Binärdateien zur Analyse an Claude hochzuladen