Supply-Chain-Angriff auf LiteLLM: Ursache war ein nicht widerrufener Master-Key und Datenabfluss über Webhooks

LiteLLM machte am 24. Oktober 2026 eine kritische Kompromittierung der Lieferkette öffentlich, die auf einen im Mai geleakten Master-Key zurückging. Ein Angreifer nutzte diesen Zugriff aus, um bösartigen Code in Version 1.107.0 des beliebten Python-Pakets einzuschleusen, mit dem Ziel, Entwickler-Zugangsdaten und Systemumgebungen zu kompromittieren.

Was passiert ist

Der Vorfall begann am 27. Mai 2026, als eine Konfigurationsdatei mit einem Master-Key für die LiteLLM Agent Platform versehentlich in ein öffentliches GitHub-Repository committet wurde. Obwohl das Team den Commit schnell per Force-Push überschrieb und die Notwendigkeit einer Sperrung erkannte, wurde der Master-Key selbst nie widerrufen. Am 10. Oktober 2026 nutzte ein Angreifer, der von der IP-Adresse 69.48.229.143 operierte, diesen weiterhin gültigen Key, um auf die Agent Platform zuzugreifen. Von dort extrahierte er ein GitHub CLI OAuth-Token, das nicht eingeschränkt war und mit dem Konto des Organisationsinhabers verknüpft war.

Mit Owner-Rechten führte der Angreifer eine Reihe von Stealth-Operationen durch. Am 10. Oktober erstellte er kurzlebige Branches in internen Repositories, um Workflows auszuführen, die darauf ausgelegt waren, zusätzliche Zugangsdaten zu ernten. Diese Branches wurden innerhalb weniger Minuten gelöscht, sodass sie in der Standard-Historie kaum Spuren hinterließen. Bis zum 21. Oktober hatte der Angreifer Branch-Schutzmechanismen außer Kraft gesetzt und die Release-Pipeline so geändert, dass sie auf ein täuschend ähnliches Repository zeigte. Er nutzte gestohlene Engineer-Tokens, um die Veröffentlichung von LiteLLM Version 1.107.0 auf PyPI, Docker Hub und GHCR auszulösen und zu genehmigen, bevor er Produktionsaufzeichnungen löschte, um seine Spuren zu verwischen.

Das bösartige Paket wurde später am selben Tag von PyPI unter Quarantäne gestellt und aus Container-Registries entfernt, nachdem Sicherheitsforscher es gemeldet hatten. LiteLLM bestätigte, dass der Angreifer die Release-Einschränkungen weiter hätte lockern können, dies aber wahrscheinlich vermied, um Entdeckung zu vermeiden. Das Unternehmen arbeitet nun daran, jedes Token zu widerrufen, das mit seinen internen Systemen und Vendor-Plattformen verknüpft ist.

Wie es funktioniert

Die primäre Methode des Angreifers zum Stehlen von Zugangsdaten bestand darin, bösartige GitHub Actions Workflows in Wegwerf-Branches einzuschleusen. Diese Workflows, benannt als cache.yml, waren so konfiguriert, dass sie bei jedem Push ausgeführt wurden. Sie sammelten Secrets wie API-Keys für Anthropic, OpenAI, AWS Bedrock und GitGuardian sowie Datenbank-Zugangsdaten und Browser-Session-States. Die gestohlenen Daten wurden an Angreifer-kontrollierte Endpunkte auf webhook.site exfiltriert, einem Dienst, der Nutzern erlaubt, eingehende HTTP-Anfragen zu inspizieren.

Nach der Veröffentlichung enthielt die kompromittierte LiteLLM-Version 1.107.0 Malware, die automatisch beim Start von Python ausgeführt wurde, selbst wenn die Bibliothek nicht importiert wurde. Die Malware umfasste ein Modul zur Ernte von Zugangsdaten, das nach Authentifizierungsmaterial in Entwickler-Tools, Cloud-Umgebungen und Browsern scannte. Außerdem installierte sie ein Unix-orientiertes Backdoor, das stündlich willkürlichen Code vom Server des Angreifers abrufte und ausführte. Dies bedeutete, dass allein das Starten von Python in einer betroffenen Umgebung den bösartigen Code aktivieren konnte, wodurch das Risiko über aktive LiteLLM-Bereitstellungen hinausging.

Wichtige Details

• Der initiale Einfallspunkt war ein Master-Key, der am 27. Mai 2026 leckte und trotz Identifikation als exponiert nie widerrufen wurde.
• Angreifer nutzten webhook.site-Endpunkte, um gestohlene Zugangsdaten zu exfiltrieren, einschließlich API-Keys und Datenbank-Passwörter.
• Bösartige Workflows wurden auf kurzlebige Branches gepusht und innerhalb von Minuten gelöscht, um Entdeckung in der Repository-Historie zu vermeiden.
• Die kompromittierte Paketversion 1.107.0 wurde am 21. Oktober 2026 auf PyPI und Container-Registries veröffentlicht.
• Die Malware führt beim Python-Start aus und enthält ein Backdoor, das sich stündlich mit litellm.dev verbindet.
• Zu den gestohlenen Zugangsdaten gehörten Zugriff auf Linear, Together AI und Secret-Scanning-Plattformen wie GitGuardian.

Warum das wichtig ist

Dieser Vorfall unterstreicht die schweren Risiken unzureichender Schlüsselverwaltung und zu weit gefasster CI/CD-Pipelines. Das Versäumnis, einen bekannten kompromittierten Key Monate nach seiner Exposition zu widerrufen, ermöglichte es dem Angreifer, persistenten Zugriff aufrechtzuerhalten. Für Engineering-Teams betont dies die Wichtigkeit, Key-Rotation als kritische Sicherheitskontrolle und nicht als optionale Wartungsaufgabe zu betrachten. Es zeigt auch, wie entspannte Release-Kontrollen, selbst für temporären Komfort, Schwachstellen schaffen können, die Angreifer nutzen, um Multi-Person-Genehmigungsprozesse zu umgehen.

Die Nutzung von Webhook-basierter Exfiltration zeigt, wie Angreifer legitime Debugging-Tools nutzen, um Daten zu stehlen, ohne traditionelle Sicherheitsalarme auszulösen. Da die Daten an externe Webhook-Endpunkte gesendet wurden, umgingen sie das interne Netzwerk-Monitoring. Entwickler und Sicherheitsingenieure müssen erkennen, dass jeder Dienst, der HTTP-Anfragen empfangen kann, als Kanal für Datenexfiltration genutzt werden kann. Das Verständnis, wie diese Anfragen strukturiert sind und was sie enthalten, ist essenziell, um solche Angriffe zu erkennen und zu verhindern.

Was Sie tun können

• Überprüfen Sie alle CI/CD-Pipelines auf zu breite Berechtigungen und stellen Sie sicher, dass Tokens auf den minimal erforderlichen Zugriff beschränkt sind.
• Implementieren Sie automatisierte Key-Rotation und sofortige Widerrufsprotokolle für alle Zugangsdaten, die in öffentlichen Repositories exponiert wurden.
• Überwachen Sie ungewöhnliche Workflow-Ausführungen, insbesondere solche, die kurzlebige Branches oder schnelle Löschungen beinhalten.
• Untersuchen Sie ausgehende HTTP-Anfragen aus Ihren Build-Umgebungen, um unbefugte Datenexfiltration zu externen Diensten zu erkennen.
• Verifizieren Sie die Integrität von Drittanbieter-Paketen durch Prüfung von Hashes und Verwendung von Lock-Files, um unerwartete Updates zu verhindern.
• Überprüfen und beschränken Sie den Zugriff auf Release-Pipelines und stellen Sie sicher, dass temporäre Lockerungen von Sicherheitskontrollen streng zeitlich begrenzt und überwacht sind.