Kompromittierung der PyPI-Pakete LiteLLM 1.82.7 und 1.82.8

• In zwei Versionen (1.82.7, 1.82.8) des weit verbreiteten LLM-Integrations-Frameworks LiteLLM wurden schädliche Payloads eingefügt und verteilt; bei der Installation kam es zu Angriffen, die System-Zugangsdaten exfiltrierten
• Ursache des Angriffs war eine Supply-Chain-Kompromittierung des CI/CD-Sicherheitsscanners Trivy, durch die CircleCI-Zugangsdaten offengelegt wurden und anschließend PyPI-Publishing-Token sowie GitHub-PATs entwendet wurden
• Nutzer des offiziellen LiteLLM Proxy Docker-Images waren nicht betroffen, da die Versionen in der requirements.txt fest fixiert sind; Umgebungen mit direktem pip install aus PyPI sollten jedoch sofort überprüft werden
• Im GitHub-Issue-Thread tauchten Hunderte Bot-Spam-Kommentare auf, die die eigentliche Diskussion behinderten; bestätigt wurde, dass Angreifer damit die Reaktionskommunikation gezielt stören wollten
• Da viele Projekte wie DSPy, CrewAI LiteLLM als Abhängigkeit nutzen, zeigte der Vorfall erneut die grundsätzliche Verwundbarkeit der Software-Supply-Chain auf

---

Überblick über den Vorfall und seine Entdeckung

• Beim Einrichten eines neuen Projekts verhielt sich das System auffällig, RAM wurde aufgebraucht und Prozesse in Form einer Forkbomb wurden gestartet
• Die Untersuchung ergab, dass in proxy_server.py ein base64-kodierter schädlicher Blob ergänzt worden war, der dekodiert, in eine separate Datei geschrieben und anschließend ausgeführt wurde
• Version 1.82.7 enthielt die Payload in litellm/proxy/proxy_server.py und wurde bei import litellm.proxy ausgeführt
• Version 1.82.8 enthielt zusätzlich die Datei litellm_init.pth, sodass bereits beim bloßen Installieren des Pakets beim Python-Start automatisch Schadcode ausgeführt wurde
  • .pth-Dateien nutzen einen Mechanismus, den Pythons site-Modul beim Start automatisch ausführt; hinter dem Schlüsselwort import kann beliebiger Code ausgeführt werden
  • Dieser Mechanismus existiert seit Python 2.1 und wurde ohne separates PEP eingeführt
• Das Team von FutureSearch meldete den ersten Schaden: uvx installierte automatisch das neueste litellm (ohne Versions-Pinning), danach lud Cursor automatisch einen lokalen MCP-Server und löste so die Infektion aus

Angriffsweg und Zusammenhang mit TeamPCP

• Der Angriff wurde denselben Akteuren zugeschrieben wie der jüngsten Kompromittierung von Trivy, der Gruppe TeamPCP
• Verlauf der Kompromittierung: Trivy-Hack → vollständiger Abfluss der CircleCI-Zugangsdaten → Diebstahl von PyPI-Publishing-Token + GitHub-PAT → Verteilung der schädlichen Pakete
• Auch die GitHub-Konten von LiteLLM-CEO und -CTO wurden vollständig übernommen; Beschreibungen privater Repositories wurden auf „teampcp owns BerriAI“ geändert und Issues geschlossen
• Das Token PYPI_PUBLISH war als Umgebungsvariable im GitHub-Projekt gespeichert und wurde über Trivy offengelegt
  • Für das Konto war 2FA aktiviert, wurde aber durch den Diebstahl des Tokens selbst umgangen
• Die Angreifer posteten in GitHub-Issues mit Hunderten Bot-Konten wiederholt identische Formulierungen und behinderten damit die echte Diskussion
  • Im Trivy-Repository wurde dasselbe Muster mit mehr als 700 Spam-Kommentaren beobachtet
  • Einige der Spam-Konten gehörten realen GitHub-Nutzern mit echter Beitrags-Historie; seit Februar wurden dort Commits mit „Update workflow configuration“ gefunden, die Credential-Stealer in CI-Workflows einschleusten
• Die Trivy-Kompromittierung lag mindestens 5 Tage zurück; da die aktuelle Angriffsmitteilung erst am Vortag veröffentlicht wurde, konnten Maintainer betroffen sein, ohne den Vorfall bereits erkannt zu haben
• Zur Auslieferung der Payload nutzten die Angreifer auch Internet Computer Protocol (ICP) Canisters, wodurch eine reine DNS-Blockade als Schutz nicht ausreicht

Funktionsweise der schädlichen Payload

• Sie erzeugte einen Python-Prozess im Hintergrund, dekodierte eingebettete Stufen und führte sie aus
• Ein Credential-Collector lief an; bei erfolgreicher Datensammlung wurde der AES-Schlüssel mit dem RSA-Public-Key des Angreifers verschlüsselt und die exfiltrierten Daten an einen Remote-Host übertragen
• In der Schadsoftware gefundene URLs: checkmarx.zone/raw und models.litellm.cloud
• Vorrangige Ziele waren vor allem SSH-Schlüssel in ~/.git-credentials sowie Informationen zu Krypto-Wallets
• Durch CPU-intensive Aktivitäten wurde das System überlastet, was die Entdeckung eher erleichterte; in manchen Fällen fiel die Anomalie durch laute Lüfter auf
• Auch bei Harbor-Installationen traten dieselben Symptome auf: Prozesse wie grep -r rpcuser\rpcpassword liefen als Forkbomb und versuchten, Krypto-Wallets aufzuspüren

Reaktion des LiteLLM-Teams

• Die betroffenen Versionen (v1.82.7, v1.82.8) wurden aus PyPI entfernt
• Passwörter aller Maintainer-Konten wurden geändert, sämtliche Schlüssel für GitHub/Docker/CircleCI/pip gelöscht und ersetzt
• Neue Maintainer-Konten wurden auf @krrish-berri-2 und @ishaan-berri umgestellt
• Das gesamte Paket wurde auf PyPI vorübergehend unter Quarantäne gestellt und nach Entfernung der infizierten Versionen wieder freigegeben
• Alle neuen Releases wurden gestoppt, die Verteilung bleibt eingefroren, bis eine vollständige Review der Supply Chain abgeschlossen ist
• Die Untersuchung und Wiederherstellung laufen in Zusammenarbeit mit Googles Mandiant-Security-Team
• Trivy wurde auf die letzte sichere Version v0.35.0 festgesetzt (nach anfänglichem Pinning auf v0.69.3 auf Basis von Community-Feedback geändert)
• Künftig werden Sicherheitsmaßnahmen wie Trusted Publishing (JWT-tokenbasiertes OIDC) und getrennte PyPI-Konten geprüft
• Der erste Veröffentlichungszeitpunkt der schädlichen Versionen lag ungefähr bei UTC 8:30, die Quarantäne auf PyPI erfolgte gegen UTC 11:25

Ausmaß der Auswirkungen und Downstream-Projekte

• LiteLLM ist die einzige Bibliothek für Aufrufe an LLM-Provider in DSPy, und CrewAI nutzt sie ebenfalls als Fallback
• Auch Airflow, Dagster, Unsloth.ai, Polar, nanobot und weitere hängen von LiteLLM ab
• Laut GitHub-Suche enthalten mehr als 628 Projekte LiteLLM in der requirements.txt ohne Versions-Pinning
• Nutzer des offiziellen Proxy-Docker-Distributionswegs waren nicht betroffen, da die requirements.txt fest gepinnte Versionen enthält
• Bei Docker-Deployments ist der Zugriff auf Host-Dateisystem und Umgebungsvariablen eingeschränkt und damit relativ sicherer; gemountete Zugangsdaten bleiben jedoch riskant
  • Hauptziel der Angreifer waren private SSH-Schlüssel; der Zugriff auf LLM-Keys war eher zweitrangig
• Auch Nutzer von Tools wie Harbor oder browser-use, die LiteLLM automatisch als Abhängigkeit installieren, meldeten indirekte Schäden
• CrewAI pinnte litellm auf 1.82.6 (letzte sichere Version), erwähnte den Vorfall im Commit-Text jedoch nicht
• DSPy reagiert mit einem öffentlich angelegten Issue
• LangChain besitzt eine eigene Schicht für Aufrufe an LLM-Provider und ist daher nicht direkt von dieser Supply-Chain-Kompromittierung betroffen (außer bei Nutzung des optionalen Pakets langchain-litellm)

Community-Diskussion: Supply-Chain-Sicherheit und Sandboxing

• Abhängigkeiten und Entwicklungsumgebungen seien nicht länger vertrauenswürdig; nötig sei Defense in Depth mit VM-Isolation + Container-Primitiven + Allowlists + Egress-Filtern + seccomp + gVisor
• Nach 50 Jahren bequemlichkeitsorientierter Sicherheitsentscheidungen sei nun eine grundlegende Neugestaltung des gesamten Sicherheitsmodells nötig
• Teilweise wurde gefordert, Sandboxing auf Programmiersprachen-Ebene pro Modul bereitzustellen
  • Java hatte diese Funktion seit den 1990ern ab v1.2, sie wurde jedoch wegen Problemen bei der Nutzbarkeit später abgeschafft
  • Manche sehen nun den richtigen Zeitpunkt für Capability-basierte Sprachen
  • Als bestehende Lösung mit Modul-Isolation wurde Cloudflares Laufzeit workerd genannt
• Auf Betriebssystem-Ebene existieren bereits Isolationswerkzeuge wie OpenBSDs pledge/unveil, Linux-Mechanismen wie chroot/namespace/cgroup sowie FreeBSDs Capsicum
• Guix kann in wenigen Sekunden isolierte Container erzeugen und Abhängigkeiten installieren, ohne auf $HOME zuzugreifen
• Werkzeuge zur Isolation im User-Space wie Firejail und bwrap sollten aktiver eingesetzt werden
• Das Modell aus Sandboxing + Berechtigungen (Intents) ist von mobilen Apps bereits bekannt, während es auf dem Desktop starke Vorbehalte gegen allgemeine Rechenbeschränkungen gibt
  • Dagegen wurde eingewandt, dass die Abgeschlossenheit von App Stores bei Apple/Meta und Sicherheits-Sandboxing zwei verschiedene Themen sind und sich Werkzeuge bauen lassen, die Nutzerkontrolle und Sicherheit zugleich ermöglichen
• Für macOS wurde ein Canary/Honeypot-Tool veröffentlicht (github.com/dweinstein/canary): Es mountet gefälschte Secrets per WebDAV/NFS, um anomale Zugriffe zu erkennen
• Manche argumentierten, zwischen Paketveröffentlichung und öffentlichem Repository müsse eine Mauer eingezogen werden; ein öffentliches Repository direkt als Trusted Publisher zu verwenden, vergrößere die Angriffsfläche
  • Die Gegenposition lautet, Trusted Publishing diene gerade dazu, eine auditierbare Verbindung zwischen Quellcode und veröffentlichtem Artefakt herzustellen; der Umweg über private Repositories wäre daher ein Rückschritt

Praktische Sicherheitsempfehlungen

• Abhängigkeiten müssen mit SHA256-Prüfsummen und fest gepinnten Versionen verwaltet werden
• Der Betrieb interner Paket-Mirror soll verhindern, dass direkt die jeweils neuesten Versionen genutzt werden
• Statt spontaner Installationen bei der Auslieferung mit uv run und ähnlichen Methoden sollten Build-Artefakte verwendet werden
  • Dadurch entfällt auch das strukturelle Risiko, dass Systeme bei einer PyPI-Störung stehen bleiben
  • Vorteile auslieferbarer Artefakte: Auditierbarkeit, schnelles Rollback und die Möglichkeit, riskante Endpunkte für ausgehenden Netzwerkverkehr zu blockieren
• Mit der Einstellung exclude-newer in uv lassen sich neu erschienene Pakete für einen bestimmten Zeitraum ausschließen
  • In der pyproject.toml ist etwa [tool.uv] exclude-newer = "5 days" möglich
• In CI/CD sollte für Publishing-Token ein OIDC-basierter Workflow eingeführt werden, um Token selbst ganz zu eliminieren
  • Sowohl GitHub als auch PyPI unterstützen OIDC: Wenn nur der Publishing-Job Zugriff auf den OIDC-Endpunkt erhält, gibt es im Trivy-Job kein stehlbares Token mehr
• Sicherheitsscanner wie Trivy sollten auf separaten Workern ohne Publishing-Rechte laufen
• Lockfile-Pflege und Updates im Wochenrhythmus helfen, die sofortige Übernahme der neuesten Versionen zu vermeiden
• Python-.pth-Dateien erlauben automatische Codeausführung; mit der Option -S lässt sich der site-Import unterdrücken, was jedoch Kompatibilitätsprobleme verursachen kann
• Es wird empfohlen, mit Tools wie osv-scanner die gesamte Projekt-Abhängigkeitskette zu überprüfen
• Befehle zur Prüfung auf eine Infektion:
  • find / -name "litellm_init.pth" -type f 2>/dev/null
  • find / -path '*/litellm-1.82.*.dist-info/METADATA' -exec grep -l 'Version: 1.82.[78]' {} \; 2>/dev/null
• Zudem wurde die Notwendigkeit einer flächendeckenden Rotation von Zugangsdaten im gesamten Paketmanager-Ökosystem angesprochen

SOC2-Audit und Vertrauensfrage

• Es wurde darauf hingewiesen, dass LiteLLMs SOC2-Auditor die zuletzt umstrittene Firma Delve war
• SOC2 prüft nur, ob dokumentierte Prozesse tatsächlich befolgt werden, garantiert aber nicht das Sicherheitsniveau selbst
• Selbst ein angemessenes SOC2 hätte diesen Supply-Chain-Angriff möglicherweise nicht verhindern können

Alternative Projekte zu LiteLLM

• Bifrost (github.com/maximhq/bifrost): Rust-basierte Alternative, auch in kostenlosen Open-Source-Instanzen mit konfigurierbaren virtuellen Schlüsseln
• Portkey (portkey.ai): Proxy-Service mit kostenlosem Tarif, laut Einschätzungen schneller als LiteLLM
• pydantic-ai: Python-basierte Alternative
• any-llm (github.com/mozilla-ai/any-llm): Projekt von Mozilla
• LLM Gateway (llmgateway.io): bietet einen LiteLLM-Migrationsleitfaden
• InferXgate (github.com/jasmedia/InferXgate): neues Projekt mit begrenzter Unterstützung für Provider
• Manche Entwickler vertreten die Ansicht, dass es bei LLM-Provider-APIs faktisch nur OpenAI und Anthropic gebe und direkte Aufrufe per requests.post() sicherer seien
  • Dem wird entgegengehalten, dass Anthropics OpenAI-kompatible API nicht als langfristige/produktive Lösung empfohlen wird und native APIs je Anbieter eigene Funktionen besitzen, die sich nicht auf die OpenAI-API abbilden lassen

[GN⁺]

Hacker-News-Kommentare

• Ich bin der Maintainer von LiteLLM. Die aktuelle Lage wird noch untersucht, aber bisher wissen wir Folgendes

  1. Das Problem scheint von trivy auszugehen, das in der CI/CD-Pipeline verwendet wurde (passender Suchlink, Analysebeitrag)
  2. Wer den proxy docker verwendet, ist nicht betroffen. Der Grund ist, dass die Version in der requirements.txt fest angeheftet war
  3. Das betroffene Paket wurde auf PyPI unter Quarantäne gestellt, sodass Downloads blockiert sind
     Wir prüfen derzeit die Ursachenanalyse und Maßnahmen zur Härtung der Sicherheit; es tut mir leid, dass dies Unannehmlichkeiten verursacht hat
  • Die betroffenen Versionen (v1.82.7, v1.82.8) wurden von PyPI entfernt. Alle Maintainer-Konten und Schlüssel (GitHub, Docker, CircleCI, pip) wurden ausgetauscht. Wir scannen weiterhin das gesamte Projekt und begrüßen Hilfe von Sicherheitsexperten (Kontakt: [e-mail])
  • Jemand meinte, mein persönliches GitHub-Konto sei womöglich ebenfalls kompromittiert worden. In den Suchergebnissen seien entsprechende Spuren zu sehen
  • Danke an diejenigen, die gesagt haben, dass mein „Es tut mir leid“ menschlich wirkte. Das Feedback, dass eine aufrichtige Reaktion besser ist als eine formelle Entschuldigung, gibt mir Kraft
  • Es gab die Frage, warum die Rotation der Zugangsdaten nicht sofort erfolgt ist. Ich werde wohl erklären müssen, warum das nicht innerhalb kurzer Zeit erkannt wurde
  • Jemand hat ein einfaches Skript erstellt und geteilt, um die installierte litellm-Version auf dem eigenen System zu finden (Skript-Link). Es ist nicht perfekt, soll aber conda-, .venv-, uv- und Systemumgebungen schnell scannen können

• Wir können Abhängigkeiten und Entwicklungsumgebungen weiterhin nicht vertrauen. Dev Container bieten zu wenig Isolation und sind zudem unkomfortabel. Wir müssen jetzt zu sandbox-basierten Entwicklungsumgebungen wechseln. Es braucht Umgebungen mit Isolation auf VM-Ebene, Egress-Filtern und Verteidigungsschichten wie seccomp und gVisor. In so einer Umgebung würde bei einer Kompromittierung der Container sofort beendet und das Problem ließe sich leichter identifizieren

  • Es wirkt, als kämen die Sicherheitsabkürzungen der letzten 50 Jahre nun als Bumerang zurück. Die auf Vertrauen basierende Entwicklungskultur geht ihrem Ende entgegen. Über einfaches Sandboxing hinaus ist eine Neugestaltung des Sicherheitsmodells selbst nötig
  • „Wie früher“ funktioniert nicht mehr. Kryptografisch verifizierbare Sicherheit ist unverzichtbar. Wir sollten in Richtung Regeln gehen, die wie bei Red Hats DISA STIG die Nutzung externer Repositories verbieten
  • Es wird um Meinungen zu meinem Projekt gebeten, das Zugangsdaten von Containern isoliert (tightbeam, airlock)
  • Ich entwickle ein Open-Source-Projekt namens smolvm (Link). Es kombiniert Isolation auf VM-Ebene mit Container-Unterstützung und zielt letztlich auf vollständige Deployments pro virtueller Maschine ab. Ich suche Leute zur Zusammenarbeit
  • Es kam die Frage auf, ob es bei jüngsten Supply-Chain-Angriffen tatsächlich zu Ausbrüchen aus Dev Containern gekommen ist

• Es wird ein für macOS entwickeltes Canary-Tool vorgestellt (Link). Es handelt sich um ein einfaches Go-Binary, das Dateien erkennt, auf die ein Paket nicht zugreifen sollte. Über WebDAV oder NFS werden falsche Geheimnisse exponiert; bei einem Zugriff wird eine Benachrichtigung gesendet. Mit diesem Honeypot-Ansatz lassen sich auffällige Aktivitäten erkennen

• Das steht im Zusammenhang mit den TeamPCP-Aktivitäten der letzten Wochen. Die von mir zusammengestellte Zeitleiste dürfte hilfreich sein

  • Es gab Rückmeldungen, dass das eine großartige Zusammenfassung sei. Allerdings wurde auch scherzhaft gesagt, die „Playlist“ sei besonders eindrucksvoll gewesen
  • Manche meinten, sie hätten den Namen TeamPCP schon an vielen Stellen gesehen, aber noch nie so übersichtlich zusammengefasst
  • Es wurde gefragt, wie man Updates so schnell aktuell halten kann

• Es wurde kritisiert, dass GitHubs Spam-Erkennungssystem viel zu schwach sei. Im litellm-Issue seien über 170 Spam-Kommentare gepostet worden

  • Dasselbe sei vor ein paar Tagen auch im trivy-Repository passiert. Nachdem Diskussionen zum Hack geschlossen worden waren, tauchten mehr als 700 Spam-Kommentare auf. Einige stammten von Konten mit echter Aktivitätshistorie. Ein Angriff zum Diebstahl von Zugangsdaten scheint weit verbreitet zu sein. Bei mehreren Konten gibt es Spuren, dass im Februar mit einem Commit namens „Update workflow configuration“ ein Credential Stealer in CI eingebaut wurde
  • Es gab Beschwerden, dass das Melden von Spam auf GitHub zu viele Schritte erfordert und daher ineffizient ist
  • Es wurde auch erwähnt, dass manche davon schlicht Bot-Konten sein könnten

• Dass so etwas irgendwann passieren würde, war zu erwarten. Man versuchte, sich durch fest angeheftete Abhängigkeitsversionen zu schützen, aber auch das ist nicht perfekt. Wegen der Komplexität der Open-Source-Supply-Chain ist es unmöglich, allen Code zu verifizieren. Durch LLMs ist das Risiko einer massenhaften Verbreitung von Schadcode wohl um das Hundertfache gestiegen

  • Es wurde angemerkt, dass das Rust-Ökosystem wegen seines tiefen Abhängigkeitsbaums schwer zu verifizieren sei. Rust, Node und Python hätten ähnliche Probleme. C/C++ sei vergleichsweise sicherer, weil dort System-Paketmanager genutzt werden und das Hinzufügen von Abhängigkeiten teurer ist

• Wenn KI-generierter Code LLVM oder Linux infiltriert, stehen wir wirklich vor dem Problem des „trusting trust“

  • Für das „Trusting Trust“-Problem wurde bereits mit Diverse Double-Compiling eine Lösung vorgeschlagen. Supply-Chain-Angriffe bleiben jedoch weiterhin schwierig. KI ist lediglich ein Werkzeug zur Skalierung von Angriffen
  • Inzwischen wirkt alles unsicher. Vielleicht sind nur noch Airgap-Umgebungen sicher. Aber die meisten Daten liegen in der Cloud, und nicht einmal deren Backups kontrollieren wir selbst
  • Es gibt Bemühungen, mit deterministischen Build-Ketten vollständig verifizierbare Software zu schaffen. Bei Debian sind 93 % der Pakete reproducible builds. Dennoch führen viele Entwickler weiterhin sorglos curl | bash aus. Der XZ-Backdoor-Vorfall war ein Beispiel, das an diese Realität erinnert hat
  • Es gab auch die Meinung, die einzige Verteidigung sei, interne APIs häufig zu ändern, damit LLMs keinen Kernel-Code lernen können
  • Wenn solche Angriffe Realität werden, könnten Regierungsserver oder Cloud-Infrastruktur massiv geschädigt werden. In Kombination mit staatlich unterstütztem Hacking könnte der Schaden Billionen Dollar erreichen. Trotzdem halte ich Linux für vergleichsweise sicher

• Es wurde erwähnt, dass LiteLLMs SOC2-Prüfstelle Delve war.

  • Ob eine SOC2-Zertifizierung solche Angriffe hätte verhindern können, wurde jedoch bezweifelt. Es wurden Erfahrungen geteilt, wonach SOC2 in der Praxis kein vollständiger Schutz ist

• Nach der Installation von Harbor schnellte die CPU auf 100 %, und das System fror ein. Ein Prozess mit grep -r rpcuser\rpcpassword schien nach Krypto-Wallets zu suchen. Immerhin wurde keine Backdoor installiert

  • Jemand berichtete von derselben Erfahrung bei browser-use. litellm sei als Abhängigkeit installiert worden und das System sei eingefroren. GitHub- und HuggingFace-Tokens wurden zwar widerrufen, aber es wurde gefragt, ob eine Neuinstallation des Betriebssystems nötig sei
  • Es gab die Frage, wie man den Prozess so schnell identifiziert habe. Ob der Activity Monitor immer geöffnet sei, wollte jemand wissen
  • Es kam auch die Frage auf, was „Harness“ eigentlich sei

• Dieser Vorfall scheint vom selben Angreifergruppierung auszugehen wie der TeamPCP-Hack von Trivy. Dass das Issue mit Bot-Kommentaren überflutet wird, ist dasselbe Muster. Sehr wahrscheinlich handelt es sich um einen automatisierten Angriff unter Einsatz von LLMs

  • Es wurde gefragt, warum die Angreifer das Issue mit Bot-Kommentaren zuspammen. Vermutlich geht es darum, Verwirrung zu stiften und die Reaktion zu verzögern