LiteLLM-Supply-Chain-Angriff: Vollständige Analyse der bösartigen Code-Injektion 2026 und Leitfaden für Notfallmaßnahmen

Wichtigste Erkenntnisse

• Betroffene Versionen: LiteLLM 1.82.7 und 1.82.8 auf PyPI wurden mit Schadcode injiziert und sind abgeschaltet worden. Die letzte sichere Version ist 1.82.6.
• Angriffsmechanismus: Version 1.82.7 versteckte die Nutzlast in proxy_server.py; Version 1.82.8 verwendete zusätzlich eine Python .pth-Datei (litellm_init.pth), die automatisch bei jedem Python-Prozessstart ausgeführt wird, ohne dass LiteLLM importiert werden muss.
• Gestohlene Daten: Private SSH-Schlüssel, AWS/GCP/Azure Zugangsdaten, Kubernetes-Konfigurationen und Secrets, .env-Dateien, Kryptowährungs-Wallets, Datenbankpasswörter, Git-Zugangsdaten, Shell-Historie und mehr.
• Dreistufiger Angriff: Erfassung von Zugangsdaten → Seitwärtsbewegung in Kubernetes (Erstellung privilegierter Pods) → Persistenz durch getarnten systemd-Dienst (sysmon.service).
• Ursache: Angreifer kompromittierten früher den Trivy Security Scanner, erhielten die PyPI-Veröffentlichungsrechte des LiteLLM-Maintainers und umgingen die normale CI/CD, um bösartige Pakete direkt hochzuladen.
• Expositionszeitraum: Die bösartigen Versionen waren nur 1–2 Stunden live, bevor ein Fork-Bomb-Fehler zu Abstürzen auf Entwicklermaschinen führte, was zur Entdeckung führte.
• Auswirkungsumfang: LiteLLM hat über 95 Millionen monatliche Downloads und wird indirekt von vielen KI-Agentensystemen, MCP-Servern und LLM-Orchestrierungsprojekten genutzt.

Zeitstrahl und Angriffsdetails

Am 24. März 2026 erschienen plötzlich anomale Versionen der beliebten LiteLLM-Bibliothek – eines vereinheitlichten API-Wrappers für über 100 LLM-Anbieter – auf PyPI. Die Bedrohungsakteure TeamPCP (zuvor verantwortlich für Angriffe auf Trivy und KICS) nutzten kompromittierte Maintainer-Zugangsdaten oder PyPI-Tokens, um zwei bösartige Versionen zu veröffentlichen.

Version 1.82.7:

• Bösartige Nutzlast versteckt in litellm/proxy/proxy_server.py.
• Wurde nur ausgelöst, wenn das Modul importiert oder litellm --proxy ausgeführt wurde.
• Die Nutzlast war ein doppelt base64-kodiertes Python-Skript.

Version 1.82.8 (destruktiver):

• Zusätzlich eingeschleuste Datei litellm_init.pth.
• Das Python-site-Modul führt .pth-Routedateien automatisch beim Interpreter-Start aus, was Auslösung ohne jegliche Interaktion ermöglicht.
• Dies bedeutete, dass selbst Projekte, die LiteLLM nie explizit nutzten, infiziert werden konnten, wenn das Paket in ihrer Umgebung vorhanden war.

Die Malware nutzte hybride Verschlüsselung (AES-256-CBC + RSA-4096), um Daten an die gefälschte Domain models.litellm.cloud zu exfiltrieren.

Technische Analyse der Schadsoftware

Die Analyse zeigt, dass die Schadsoftware in drei aufeinanderfolgenden Stufen operierte:

1. Phase der Zugangsdaten-Ernte (Credential Harvesting):

   • Rekursives Scannen häufiger Pfade: ~/.ssh/, ~/.aws/, ~/.kube/, ~/.azure/, .env-Dateien, Kubernetes-Konfigurationen, Git-Credentials usw.
   • Extraktion von Umgebungsvariablen, geheimen Schlüsseln im Arbeitsspeicher, Cloud-Metadaten-Endpunkten (IMDS) und zahlreichen Kryptowährungs-Wallet-Dateien.

2. Phase der lateralen Bewegung (Lateral Movement) in Kubernetes-Umgebungen:

   • Verwendung von ServiceAccount-Token zum Lesen clusterweiter Secrets.
   • Erstellung privilegierter alpine:latest-Pods im kube-system-Namespace auf jedem Knoten mit eingebundenem Host-Dateisystem.

3. Phase der Persistenz (Persistence):

   • Installation einer als "System-Telemetrie-Dienst" getarnten Backdoor (sysmon.py + systemd-Benutzerservice).
   • Periodischer Abruf zusätzlicher Nutzdaten von Domains wie checkmarx.zone.

Auslöser für die Entdeckung: Die subprocess.Popen-Aufrufe des schädlichen Codes erzeugten eine exponentielle Fork-Bombe unter dem .pth, Mechanismus, die den Arbeitsspeicher rasch erschöpfte und Maschinen zum Absturz brachte – ein Fehler, der den Angriff unbeabsichtigt aufdeckte.

Warum LiteLLM ein lohnendes Ziel war

LiteLLM dient als universeller Proxy, der über 100 LLM-Anbieter unterstützt und wird häufig in produktiven KI-Agenten-Systemen, MCP-Servern und Multi-Model-Routing eingesetzt. Entwickler ersetzen häufig zugrunde liegende Aufrufe durch eine einzelne Codezeile, was bedeutet, dass sensible API-Schlüssel oft in derselben Umgebung koexistieren.

Die Lieferketten-Angriffskette war eindeutig: Kompromittierung von Trivy → CI/CD von LiteLLM, das auf Trivy angewiesen ist → Veröffentlichungsrechte-Leak → Direkter Upload der Schadsoftware zu PyPI. Dies unterstreicht die entscheidende Bedeutung von "Vertrauen, aber verifizieren" im heutigen Open-Source-Ökosystem.

Sofortmaßnahmen: Schritte zur Erkennung und Bereinigung

Schritt 1: Überprüfung der installierten Version

pip show litellm
pip list | grep litellm

Wenn Version 1.82.7 oder 1.82.8 gefunden wird, entfernen Sie diese sofort:

pip uninstall litellm -y
pip install litellm==1.82.6 --force-reinstall

Schritt 2: Bereinigung des Python-Cache und der site-packages -Die site-packages/litellm*-Verzeichnisse und alle .pth-Dateien löschen. -Pip-Cache bereinigen: pip cache purge

Schritt 3: Erneuerung aller Zugangsdaten

• Sofort SSH-Schlüssel, alle Cloud-Zugangsschlüssel (AWS IAM, GCP Service Accounts, Azure AD), Kubernetes-Token, Datenbankpasswörter und CI/CD-Secrets erneuern.
• Cloud-Audit-Logs (CloudTrail, Audit Logs, Activity Log) auf verdächtige Zugriffe überprüfen.

Schritt 4: Zusätzliche Kontrollen für Kubernetes-Umgebungen

• kube-system-Namespace auf verdächtige Pods scannen.
• Nach ~/.config/sysmon/-Verzeichnissen und nicht autorisierten systemd-Services auf Knoten suchen.
• Betroffene Knoten neu aufbauen (stark empfohlen).

Schritt 5: Scannen abhängiger Projekte

• Alle requirements.txt, pyproject.toml und Docker-Images auditieren; LiteLLM auf ==1.82.6 fixieren.
• Tools wie pip-audit oder safety verwenden, um Umgebungen zu scannen.

Erweiterte Risikominimierung und Best Practices

• Versionsfixierung: Fixieren Sie LiteLLM in Produktionsumgebungen auf ==1.82.6 (oder eine neuere sichere Version) mithilfe von Poetry, Pipenv oder ähnlichen Tools.
• Lieferkettenüberprüfung: Integrieren Sie Dependabot, Snyk, JFrog Xray oder Endor Labs, um Änderungen an PyPI-Paketen zu überwachen.
• Prinzip der geringsten Rechte: Vermeiden Sie die Vermischung von Entwicklungs- und Produktionszugangsdaten; verwenden Sie dedizierte Secrets Manager (AWS Secrets Manager, HashiCorp Vault).
• Air-gapped Installation: In Hochsicherheitsumgebungen aus verifizierten GitHub-Quellen bauen und Hashwerte prüfen.
• Monitoring: Implementieren Sie EDR-Lösungen, um die Erstellung von .pth-Dateien, abnormales Fork-Verhalten und ausgehende Verbindungen zu verdächtigen Domains zu überwachen.

Sonderfälle:

• Indirekte Installation über CLI-Skripte (install.sh) kann Systeme ebenfalls gefährden. -T Docker-Images, die auf kompromittierten Basis-Images basieren, müssen neu erstellt werden.
• Virtuelle Umgebungen (venv) sind isoliert, aber globale Python-Installationen können trotzdem Systemprozesse beeinflussen.

Fazit

Der Lieferkettenangriff auf LiteLLM dient als deutliche Erinnerung, dass die Bequemlichkeit von Open-Source-Ökosystemen mit ernsten Sicherheitsrisiken einhergeht. Durch die Kompromittierung eines Sicherheits-Scanners zuerst erzielten die Angreifer präzise nachgelagerte Wirkung.

Handeln Sie jetzt: Überprüfen Sie jede Python-Umgebung auf LiteLLM-Versionen, stufen Sie auf 1.82.6 zurück und rotieren Sie alle potenziell exponierten Zugangsdaten sofort. Etablieren Sie strenge Abhängigkeitsprüfprozesse, um zukünftige Vorfälle zu verhindern.

Bleiben Sie über die offiziellen LiteLLM-GitHub- und PyPI-Ankündigungen auf dem Laufenden. In 2026 und darüber hinaus ist regelmäßiges Abhängigkeits-Auditing eine essentielle Fähigkeit für jeden KI-Entwickler.

Bleiben Sie wachsam und schützen Sie die Lieferkette – beginnen Sie noch heute mit der Versionsfixierung.