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

Ein Python-Paket aktualisieren, einen Agenten neu starten – und plötzlich liegen Modellzugänge, Cloud-Rollen oder CI-Tokens in der Reichweite von Schadcode. Genau dieses Risiko zeigte der LiteLLM-Vorfall vom 24. März 2026.

Die Versionen litellm==1.82.7 und litellm==1.82.8 wurden laut OSV-Sicherheitsmeldung mit Malware veröffentlicht und später entfernt.¹ LiteLLM sitzt in vielen Agenten-Stacks zwischen Anwendung und Modellanbietern. Ein kompromittiertes Paket an dieser Stelle kann deshalb mehr berühren als eine einzelne Bibliothek.

Was betroffene Teams prüfen sollten

Wenn eine der betroffenen Versionen installiert war, zählt Geschwindigkeit. Behandle den Host als potenziell exponiert, bevor du nach einer eleganten technischen Erklärung suchst.

1. Isoliere die betroffene Umgebung vom Netzwerk, sofern sie noch aktiv ist.
2. Ermittle, ob eine verwundbare LiteLLM-Version installiert oder in einem Build-Artefakt enthalten war.
3. Rotiere alle Secrets, die dieser Umgebung erreichbar waren. Dazu gehören typischerweise Modell- und Cloud-Zugänge; je nach Rolle des Hosts auch Datenbank- oder CI-Credentials.
4. Prüfe ausgehenden Traffic, Prozessdaten und Logs auf ungewöhnliche Aktivitäten.
5. Sichere Belege für die Incident-Analyse, bevor du Container oder Hosts bereinigst.

Prüfe die installierte Version mit einem lesenden Befehl:

pip show litellm

Die weitere Bereinigung sollte sich an der aktuellen Sicherheitsmeldung, dem eigenen Incident-Runbook und den tatsächlichen Zugriffsrechten der Umgebung orientieren.¹

Zwei Wege in dieselbe Lieferkette

Die technische Analyse zum Vorfall beschreibt unterschiedliche Platzierungen des Schadcodes.¹² In Version 1.82.7 befand er sich im Proxy-Pfad. In Version 1.82.8 nutzte der Angriff eine litellm_init.pth-Datei.

Das ist für Python-Umgebungen wichtig: .pth-Dateien können beim Start des Interpreters geladen werden. Eine einmal installierte kompromittierte Abhängigkeit kann damit über den normalen Startpfad erneut aktiv werden.

Prüfe deshalb nicht nur die aktuell sichtbare Paketversion. Sieh dir auch virtuelle Umgebungen, Container-Images, Build-Caches und Deployment-Artefakte an. Gerade ein bereits gebautes Image kann eine entfernte PyPI-Version noch weitertragen.

Warum Gateway-Pakete ein großer Hebel sind

LiteLLM vereinheitlicht in vielen Projekten Zugriffe auf Modellanbieter. Solche Gateways sehen häufig API-Schlüssel, Routing-Informationen, Logs und Verbindungsdaten. Der mögliche Schaden hängt daher von der Umgebung ab: Ein lokaler Testcontainer ist etwas anderes als ein Produktionsgateway mit Zugang zu Cloud, Datenbank und CI.

Die dokumentierte Malware zielte auf verfügbare Konfigurationen und Secrets.¹² Für Betreiber folgt daraus eine einfache Priorität: Rotationen und Zugriffsbeschränkungen gehören vor die Suche nach dem vollständigen Payload-Verständnis.

KI kann die Analyse beschleunigen – in einer isolierten Umgebung

Ein Sprachmodell kann bei einem Security-Incident helfen, verdächtige Dateien zu strukturieren, Obfuskation zu erklären oder Checklisten aus Logs abzuleiten. Es ist kein Detektionssystem und keine Freigabeinstanz.

Lade verdächtige Pakete oder Dateien dafür niemals unkontrolliert in deine Arbeitsumgebung. Nutze eine isolierte Analyseumgebung ohne produktive Secrets und ohne Zugang zu internen Netzen. Gib dem Modell nur Material, das für die Analyse erforderlich ist, und prüfe seine Schlussfolgerungen gegen Logs, Hashes und Sicherheitsmeldungen.

Das spart Zeit bei der Triage. Die Verantwortung für Isolierung, Rotation und Wiederinbetriebnahme bleibt beim Incident-Team.

Prävention: Abhängigkeiten wie Infrastruktur behandeln

Ein Package-Manager ist Teil deiner Infrastruktur. Sichere Agenten-Stacks deshalb mit konkreten Kontrollen:

• Versionen pinnen und für kritische Abhängigkeiten Hashes erzwingen.
• Container-Images und Lockfiles auf verwundbare Versionen prüfen.
• SBOMs und Abhängigkeits-Scans in den Build integrieren.
• Secrets so begrenzen, dass ein einzelner Host nicht alle Zugänge auslesen kann.
• Verdächtige Updates erst in einer getrennten Umgebung testen.

Ich würde Gateway-Bibliotheken besonders streng behandeln. Sie liegen an einer Stelle, an der Modellzugang, Nutzerdaten und Infrastruktur oft zusammenkommen. Ein schneller Update-Workflow ohne Versionskontrolle ist dort kein Komfortgewinn, sondern eine offene Flanke.

Der Prüfstein für deinen Stack

Nach einem Supply-Chain-Vorfall ist die wichtigste Frage nicht, ob PyPI das Paket entfernt hat. Entscheidend ist, ob du feststellen kannst, wo die Version gelaufen ist, welche Secrets sie erreichen konnte und wie du betroffene Zugänge schnell abschaltest.

Wenn diese Antworten fehlen, ist das der nächste Sicherheitsauftrag. Agenten-Stacks brauchen neben Modell- und Framework-Evaluierung auch Paketquellen, Hashes, Registry-Strategie und Secret-Hygiene.

Footnotes

1. https://osv.dev/vulnerability/PYSEC-2026-56 ↩ ↩² ↩³ ↩⁴

2. https://www.kaspersky.com/blog/litellm-supply-chain-attack/54496/ ↩ ↩²