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

Im März 2026 wurden LiteLLM-Versionen 1.82.7 und 1.82.8 über PyPI mit bösartigem Code kompromittiert. Dieser umfassende Leitfaden erklärt den Angriff, gestohlene Daten und exakte Schritte zur sofortigen Überprüfung, Bereinigung und Rotation von Zugangsdaten.

Canonical URL: https://a2a-mcp.org/blog/litellm-supply-chain-attack-2026-de

Language: de

Published: 2026-03-25

Updated: 2026-03-25

## 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**
```bash
pip show litellm
pip list | grep litellm
```

Wenn Version 1.82.7 oder 1.82.8 gefunden wird, entfernen Sie diese sofort:
```bash
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.