Manipulierte LiteLLM-Version 1.107.0 stiehlt Zugangsdaten und öffnet Hintertüren
Angreifer haben den Veröffentlichungsprozess des Open-Source-Projekts LiteLLM kompromittiert und am 21. Oktober 2026 eine manipulierte Version auf PyPI veröffentlicht. LiteLLM 1.107.0 enthielt Schadcode, der Zugangsdaten aus Entwicklungsumgebungen auslesen und weiteren Code von externen Servern nachladen konnte. Betroffen waren potenziell auch Python-Umgebungen, in denen LiteLLM zwar installiert, aber nicht aktiv verwendet wurde.
Ausgangspunkt des Angriffs war ein Konfigurationsfehler vom 27. Mai 2026. Damals gelangte eine Datei mit Zugangsschlüsseln in ein öffentliches LiteLLM-Repository auf GitHub. Obwohl die Schlüssel als kompromittiert erkannt wurden, blieb ein Master-Key für die LiteLLM Agent Platform gültig.
Am 10. Oktober nutzte ein Angreifer diesen Schlüssel, um auf die Agent Platform zuzugreifen. Dort konnte er unter anderem ein OAuth-Token der GitHub CLI auslesen, das von selbst gehosteten Cloud-Agenten verwendet wurde. Das Token gehörte zum Konto des GitHub-Organisationsinhabers und verfügte über weitreichende Berechtigungen. Damit erhielt der Angreifer Zugriff auf die Repositories der gesamten Organisation.
Weitere Zugangsdaten über GitHub Actions abgegriffen
Mit den erlangten Berechtigungen legte der Angreifer temporäre Branches und GitHub-Actions-Workflows an. Diese wurden genutzt, um zusätzliche Zugangsdaten aus der Entwicklungs- und Build-Infrastruktur auszulesen.
Zu den Zielen gehörten GitHub-Tokens, der private Signaturschlüssel einer GitHub-App sowie Zugangsdaten für Linear und interne LiteLLM-Systeme. Später kamen Schlüssel für Anthropic, OpenAI, AWS Bedrock, Tavily und GitGuardian hinzu. Auch Datenbankzugänge, Redis-Konfigurationen und Browser-Sitzungsdaten wurden abgegriffen und an externe Webhook-Adressen übertragen.
Die verwendeten Branches und Workflow-Dateien waren nur kurzzeitig vorhanden. Dadurch hinterließ der Angriff vergleichsweise wenige Spuren im regulären Repository-Verlauf.
Manipulierter Release-Prozess veröffentlicht Schadcode
Im nächsten Schritt veränderte der Angreifer die Release-Pipeline. Statt ausschließlich auf den offiziellen Quellcode zuzugreifen, verwendete der Build-Prozess ein täuschend ähnliches Repository unter Kontrolle des Angreifers.
Am 21. Oktober wurde auf diesem Weg LiteLLM 1.107.0 auf PyPI veröffentlicht. Gleichzeitig erschienen manipulierte Container-Images auf Docker Hub und GitHub Container Registry (GHCR).
Eine vorübergehende Änderung der Freigaberegeln erleichterte den Angriff. Während Veröffentlichungen normalerweise die Zustimmung eines besonders abgesicherten Accounts erforderten, konnten zeitweise zwei beliebige Entwickler den Release auslösen und genehmigen.
PyPI stellte die betroffene Paketversion später unter Quarantäne. Die manipulierten Container-Tags wurden entfernt oder auf überprüfte, nicht kompromittierte Images umgestellt.
Schadcode wird bereits beim Python-Start aktiv
Besonders kritisch war die Art, wie die Schadsoftware in das Python-Paket integriert wurde. Die manipulierten Dateien waren so platziert, dass sie bereits beim Start des Python-Interpreters ausgeführt werden konnten. Ein aktiver Import von LiteLLM war dafür nicht erforderlich.
Ein Teil des Schadcodes sammelte Zugangsdaten aus Entwicklerwerkzeugen, KI-Anwendungen, Cloud-Umgebungen und Browsern. Eine weitere Komponente startete unter Unix als Hintergrundprozess und konnte stündlich neuen Code von einem externen Server abrufen und ausführen.
Die schädlichen Startdateien befanden sich außerhalb des eigentlichen LiteLLM-Paketverzeichnisses. Wer lediglich die LiteLLM-Anwendungsdateien löschte, konnte deshalb Teile der Schadsoftware auf dem System zurücklassen.
Was betroffene Entwickler und Betreiber prüfen sollten
LiteLLM 1.107.0 sowie die im Vorfall identifizierten manipulierten Container-Versionen sollten nicht mehr verwendet werden. Systeme, auf denen die betroffene Version ausgeführt wurde, müssen als potenziell kompromittiert betrachtet werden.
Neben der Entfernung des Pakets sollten insbesondere Python-Startdateien, verdächtige Hintergrundprozesse und ausgehende Verbindungen überprüft werden. Zugangsdaten, die in den betroffenen Umgebungen verfügbar waren, müssen auf möglichen Missbrauch untersucht und gegebenenfalls erneuert werden. Dazu zählen auch API-Schlüssel, CI/CD-Tokens und Cloud-Zugangsdaten.
LiteLLM erklärte, an der Sperrung betroffener Tokens für interne Systeme und angebundene Dienstleister zu arbeiten. Welche Ersatzversion uneingeschränkt verwendet werden kann und welche vollständigen Bereinigungsschritte für betroffene Installationen erforderlich sind, ging aus dem veröffentlichten Bericht nicht hervor.