Supply-Chain-Angriff auf LiteLLM stiehlt Zugangsdaten über geleakte GitHub-Tokens

Am 21. Oktober 2026 haben Bedrohungsakteure die Release-Pipeline von LiteLLM, einer Open-Source-Bibliothek für AI-Gateways, kompromittiert, um eine schädliche Version ihrer Software zu verteilen. Die Angreifer nutzten geleakte GitHub CLI OAuth Tokens, die vermutlich aus Anwendungslogs entnommen wurden, um Sicherheitskontrollen zu umgehen und vergiftete Artefakte an große Paket-Registries zu pushen.

Was passiert ist

Der Vorfall begann gegen 4:00 Uhr PST, als die Angreifer LiteLLM Version 1.107.0 im Python Package Index (PyPI), auf Docker Hub und im GitHub Container Registry (GHCR) veröffentlichten. Diese kompromittierte Version enthielt einen Credential Stealer und eine Backdoor, die darauf ausgelegt war, Secrets von betroffenen Systemen zu ernten. Benutzer, die zwischen 11:39 und 13:23 UTC unpinned Versionen über pip herunterluden oder spezifische Docker Tags zwischen 11:46 und 14:20 UTC zogen, waren der Malware ausgesetzt.

Der schädliche Code nutzte einen Dual-Technique-Ansatz, um Persistenz und Ausführung sicherzustellen. Er verwendete eine Python-Pfad-Datei namens "cook.pth", um ein Skript namens "cook.py" zu importieren, das sich selbst deobfuskierte, um eine Routine namens "privcollect" auszuführen. Diese Routine sammelte System-, Browser-, Cloud- und AI-Tool-Secrets und exfiltriierte sie auf eine angreiferkontrollierte Domain. Zusätzlich führte die Malware auf Linux- und macOS-Maschinen "sitecustomize.py" aus, um weitere Anweisungen aus einem GitHub Repository abzurufen, wodurch ein Remote Access Trojaner etabliert wurde, der stündlich nach neuen Befehlen pollte.

Die Maintainer von LiteLLM führten den Einbruch auf eine Kombination aus operativen Änderungen und Log-Exposure zurück. Obwohl das Projekt seine Release-Pipeline kürzlich durch Signieren von Images und die Nutzung privater Repositories gehärtet hatte, wurden die Berechtigungen vorübergehend erweitert, damit zwei Ingenieure tägliche Bugfixes veröffentlichen konnten. Die Angreifer griffen auf drei Sätze von Entwickler-GitHub-CLI-Credentials zu und vermuteten, dass diese Tokens in Response Bodies eingebettet waren, die von einer internen, ins Internet exponierten LiteLLM-Deployment geloggt wurden. Ein Token eines Organisations-Inhabers ermöglichte es dem Angreifer, Branch-Protections zu deaktivieren und böswillige Änderungen per Force-Push in ein Lookalike-Repository einzuspielen, was den CI/CD-Workflow dazu brachte, die vergifteten Artefakte zu signieren und zu veröffentlichen.

Wichtige Details

• Kompromittierte Versionen: LiteLLM v1.107.0 auf PyPI; v1.107.0, latest, main-latest und main-stable auf Docker und GHCR.
• Auswirkungszeitraum: PyPI-Nutzer zwischen 11:39 und 13:23 UTC; Docker-Nutzer zwischen 11:46 und 14:20 UTC am 21. Oktober 2026.
• Malware-Verhalten: Erntet Credentials via "privcollect" und etabliert einen stündlichen Beacon zu einem Command-and-Control-Server unter Nutzung von GitHub als Dead Drop.
• Angriffsvektor: Geleakte GitHub CLI OAuth Tokens, die in LiteLLM Logs gefunden wurden, wurden zur Authentifizierung und Manipulation des Release-Workflows verwendet.
• Post-Exploitation: Gestohlene AWS-Credentials wurden innerhalb von 4,5 Stunden validiert, wobei die Angreifer LLMjacking-Aktivitäten wie das Auflisten von Foundation Models durchführten.
• Mitigationsstatus: GitHub entfernte das bösartige Repository gegen 13:30 UTC; LiteLLM hat seitdem Berechtigungen widerrufen und Credentials rotiert.

Hintergrund

Supply-Chain-Angriffe zielen auf die Abhängigkeiten und Build-Prozesse von Software ab, nicht direkt auf Endbenutzer-Anwendungen. In diesem Fall mussten die Angreifer keine Schwachstelle im LiteLLM-Code selbst ausnutzen, sondern kompromittierten stattdessen den Mechanismus, der zur Verteilung genutzt wird. Durch das Injizieren von schädlichem Code in das offizielle Paket, dem Tausende von Entwicklern vertrauten, stellten sie eine weitreichende Verbreitung ohne sofortiges Misstrauen sicher.

Die Nutzung von GitHub CLI OAuth Tokens hebt ein häufiges Risiko in modernen Entwicklungsworkflows hervor. Diese Tokens gewähren programmatischen Zugriff auf GitHub-Ressourcen und können hochprivilegiert sein. Wenn solche Tokens versehentlich im Klartext geloggt werden – oft durch AI-Coding-Assistenten oder verbose Application Logs –, werden sie zu leichten Zielen für Angreifer, die nach zugänglichen Credentials scannen. Einmal erhalten, können diese Tokens Multi-Factor Authentication umgehen, wenn die Session noch aktiv ist, sodass Angreifer als legitime Entwickler agieren können.

Warum es wichtig ist

Für Teams, die ihre eigene Software betreiben, unterstreicht dieser Vorfall die Fragilität des Vertrauens in Open-Source-Abhängigkeiten. Selbst Projekte mit robusten Sicherheitspraktiken, wie signierten Artefakten und immutablen Tags, können kompromittiert werden, wenn menschlich gesteuerte Workflows geschwächt werden. Die vorübergehende Erweiterung der Release-Berechtigungen, die die Developer Velocity verbessern sollte, schuf eine Angriffsfläche, die Gegner ausnutzten. Dies dient als Erinnerung daran, dass Komfortfunktionen in CI/CD-Pipelines sorgfältig scoped und überwacht werden müssen.

Darüber hinaus ist die Exposure von Credentials durch Logging ein persistentes Hygiene-Problem. Viele Self-Hosted-Anwendungen und AI-Gateways loggen Request- und Response-Bodies zu Debugging-Zwecken. Wenn diese Logs sensible Tokens oder Keys enthalten, kann jeder Bruch der Logging-Infrastruktur – oder sogar eine versehentliche öffentliche Exposition eines Debug-Endpoints – zu einer katastrophalen Kompromittierung führen. Teams müssen davon ausgehen, dass Logs potenzielle Secret Stores sind, und sie mit derselben Sicherheitsrigorosität behandeln wie Datenbankinhalte.

Die Geschwindigkeit, mit der die Angreifer gestohlene Credentials nutzten, demonstriert die Dringlichkeit des Incident Responses. Innerhalb weniger Stunden nach der Exfiltration enumerierten die Gegner aktiv Cloud-Ressourcen und validierten den Zugriff. Für IT- und DevOps-Leads bedeutet dies, dass Erkennungs- und Rotierungsmechanismen automatisiert und unmittelbar sein müssen. Das Warten auf manuelle Untersuchungen vor der Rotation von Keys gibt Angreifern ample Zeit, Persistenz zu etablieren und lateral within cloud environments zu bewegen.

Was Sie tun können

• Installierte Versionen prüfen: Verifizieren Sie sofort, ob LiteLLM v1.107.0 oder eine der betroffenen Docker Tags in Ihrer Umgebung vorhanden sind, und entfernen Sie sie, falls gefunden.
• Alle Credentials rotieren: Gehen Sie davon aus, dass alle Secrets, die auf Systemen gespeichert waren, die die kompromittierte Version ausgeführt haben, exponiert sind. Rotieren Sie API Keys, Cloud-Credentials und GitHub Tokens sofort.
• Logs auf Tokens auditieren: Überprüfen Sie Ihre Application- und AI-Gateway-Logs, um sicherzustellen, dass keine OAuth Tokens oder Secrets im Klartext aufgezeichnet werden. Implementieren Sie Log-Sanitization-Filter.
• Release-Berechtigungen einschränken: Vermeiden Sie vorübergehende Erweiterungen von Release-Privilegien. Nutzen Sie bei Bedarf kurzlebige, scoped Tokens und erzwingen Sie zusätzliche Approval-Schritte für die Veröffentlichung in öffentlichen Registries.
• Dependency-Versionen pinnen: Pinchen Sie immer spezifische Versionen von Third-Party-Libraries in Ihren Requirements Files, um die automatische Installation potenziell kompromittierter Updates zu verhindern.
• Auf verdächtige Aktivitäten überwachen: Prüfen Sie Cloud Audit Logs auf ungewöhnliche API Calls, wie unerwartete Model Listings oder IAM Enumeration, die auf LLMjacking-Versuche hinweisen könnten.