Back to Blog
BlogMarch 25, 20262

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

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.

Share this article