🔑 Wichtigste Zusammenfassung
Über eine Schwachstelle in einer Trivy-Abhängigkeit wurden API-Tokens entwendet; darauf aufbauend wurden bösartige Versionen der Pakete litellm und telnyx auf PyPI veröffentlicht. Der Schadcode wurde sofort bei der Installation ausgeführt, sammelte sensible Zugangsdaten und Dateien und leitete sie anschließend an einen externen Server weiter.
⚠️ Warum diese Malware besonders ist
Die meisten bisherigen bösartigen Pakete auf PyPI waren neu erstellte Pakete (z. B. Typosquatting). Dieser Angriff ist anders. Hier wurde Schadcode in bereits weit verbreitete Open-Source-Pakete eingeschleust.
Es gab zwei Wege für die Einschleusung:
- direkter Angriff auf Open-Source-Projekte mit schwach gesicherten Repositories, Release-Workflows oder Authentifizierung
- Entwendung von API-Tokens und Schlüsseln von Entwicklerrechnern, die automatisch die neueste Version installieren
Mit den erbeuteten PyPI- oder GitHub-API-Tokens wurden dann weitere Open-Source-Pakete kompromittiert – eine kaskadierende Angriffskette.
📅 Zeitleiste des Vorfalls
LiteLLM
Während des Expositionszeitraums der bösartigen Versionen wurde das Paket mehr als 119.000 Mal heruntergeladen.
PyPI erhielt 13 Meldungen über die Funktion "Malware melden".
| Phase | Dauer |
|---|---|
| Upload → erste Meldung | 1 Stunde 19 Minuten |
| Erste Meldung → Quarantäne | 1 Stunde 12 Minuten |
| Gesamte Expositionszeit | 2 Stunden 32 Minuten |
LiteLLM wird pro Woche etwa 15 bis 20 Millionen Mal installiert, also rund 1.700 Installationen pro Minute. Davon erhielten etwa 40–50 % ohne Versionsfixierung automatisch die jeweils neueste Version.
Telnyx
Beim Paket telnyx erfolgte dank des Pools vertrauenswürdiger Hinweisgeber (trusted reporters) auf PyPI eine automatische Quarantäne.
| Phase | Dauer |
|---|---|
| Upload → erste Meldung | 1 Stunde 45 Minuten |
| Erste Meldung → Quarantäne | 1 Stunde 57 Minuten |
| Gesamte Expositionszeit | 3 Stunden 42 Minuten |
🛡️ Sicherheitsempfehlungen für Entwickler
1. Dependency Cooldowns
Dabei wird konfiguriert, dass kürzlich veröffentlichte Pakete für einen bestimmten Zeitraum nicht installiert werden, damit Sicherheitsforscher und die PyPI-Administration Zeit für Gegenmaßnahmen haben.
uv — wird derzeit unterstützt:
# ~/.config/uv/uv.toml oder pyproject.toml
[tool.uv]
exclude-newer = "P3D" # Pakete ausschließen, die innerhalb der letzten 3 Tage veröffentlicht wurden
pip v26.1 — Unterstützung im April geplant:
# ~/.config/pip/pip.conf
[install]
uploaded-prior-to = P3D
> ⚠️ Cooldowns sind kein Allheilmittel. Wenn ein Sicherheits-Patch benötigt wird, muss er sofort installiert werden; deshalb sollten sie zusammen mit Schwachstellen-Scan-Tools wie Dependabot oder Renovate eingesetzt werden.
2. Dependency Locking (Lock Files)
pip freeze, das nur Versionen festhält, ist keine Lock-Datei. Für Sicherheit wird eine echte Lock-Datei benötigt, die Prüfsummen/Hashes enthält.
Empfohlene Tools:
uv lockpip-compile --generate-hashespipenv
🔒 Sicherheitsempfehlungen für Open-Source-Maintainer
1. Release-Workflow besser absichern
- Keine unsicheren Trigger verwenden —
pull_request_targetin GitHub Actions ist besonders riskant - Parameter und Eingaben entschärfen — per Umgebungsvariablen übergeben, um Template Injection zu vermeiden
- Keine veränderlichen Referenzen verwenden — Commit-SHA statt Git-Tags nutzen, Lock-Dateien für Abhängigkeiten pflegen
- Deployments mit Review-Pflicht konfigurieren — mit Trusted Publishers + GitHub Environments zusätzliche Freigaben vor der Veröffentlichung verlangen
Wer GitHub Actions nutzt, sollte das Tool Zizmor verwenden, um Workflow-Schwachstellen zu prüfen.
2. Trusted Publishers statt API-Tokens verwenden
- API-Tokens sind langfristig gültig, daher ist ein Diebstahl nicht sofort zu erkennen
- Trusted Publishers verwenden kurzlebige Tokens; selbst wenn sie entwendet werden, müssen sie sofort genutzt werden, was das Risiko senkt
- Mit Digital Attestations können nachgelagerte Nutzer Deployments erkennen, die nicht über den legitimen Release-Workflow erfolgt sind
3. 2FA verpflichtend aktivieren
PyPI hat 2024 2FA für Paketveröffentlichungen verpflichtend gemacht. Aber nicht nur für das PyPI-Konto, sondern für alle Konten, die mit der Open-Source-Entwicklung zusammenhängen – etwa GitHub, GitLab oder E-Mail –, sollte 2FA aktiviert werden, wenn möglich mit einem Hardware-Key.
💰 Wer diese Arbeit unterstützen möchte
Die Sicherheitsarbeit von PyPI wird durch Unterstützung der Python Software Foundation (PSF) ermöglicht. Unterstützung ist über das PSF-Sponsoring-Programm, direkte Spenden oder per Anfrage an sponsors@python.org möglich.
> Die Stellen von Mike Fiedler und Seth Larson als PyPI-Sicherheitsingenieure werden von Alpha-Omega gefördert.
1 Kommentare
Ich habe mal einen MCP-Server gebaut und auf npm hochgeladen, und dieser Vorfallbericht war schon ziemlich beklemmend.
MCP-Server landen am Ende ja ebenfalls direkt auf npm und PyPI, und nicht wenige werden installiert, ohne Versionen festzupinnen; außerdem gibt es Dinge wie ein Meldesystem oder Trusted Publisher dort noch nicht. Obwohl LiteLLM nur etwas mehr als zwei Stunden exponiert war, waren die Download-Zahlen schon so hoch, dass ich dachte: Wenn so etwas hier einmal eindringt, bleibt es vermutlich ziemlich lange bestehen.
Bei Claude Code scheint es auch Fälle zu geben, in denen solche Schutzmechanismen bei
pip installnicht sauber greifen. Wenn der Agent den Paket-Installationsfluss eigenständig ausführt, ist es unklar, an welcher Stelle man das überhaupt blockieren sollte.