Supply-Chain-Angriff auf LiteLLM, Zeabur-Vorfall, Gheist

Illustration einer Sprechblase mit dem Text „Cybersecurity News Weekly“ und einem gelben Blitz: wöchentlicher Überblick über Cybersicherheitsnachrichten zum Supply-Chain-Angriff auf LiteLLM, Zeabur und Gheist

Ein Schlüssel, der im Mai in ein öffentliches Repository committet wurde, ermöglichte im Oktober einen Supply-Chain-Angriff über ein manipuliertes Release eines weit verbreiteten KI-Gateways. Im Abstand weniger Tage räumte eine Hosting-Plattform ein, dass Admin-Token, die seit Januar 2024 unverändert geblieben waren, den Weg in ihre Produktionssysteme geöffnet hatten.

Diese Vorfälle haben eine gemeinsame Schwachstelle: Zugangsdaten, die noch lange gültig blieben, obwohl sie längst hätten widerrufen, eingeschränkt oder rotiert werden müssen. Nachfolgend fünf Vorfälle, was jeder einzelne zeigt und was Sie zuerst prüfen sollten.

LiteLLM: Ein nicht widerrufener Master-Key führte laut LiteLLM und Microsoft zu einem gestohlenen GitHub-Token eines Organisationsbesitzers und zu einem bösartigen Release
Zeabur: Admin-Token im Klartext und ohne Ablaufdatum legten 321.810 Konten offen, so Zeabur
Gheist: Mit gestohlenen GitHub-Token werden Workflows platziert, die Repository-Secrets in Logs ausgeben, berichtet Help Net Security
PingCAP: Gestohlene Zugangsdaten verschafften Angreifern laut PingCAP über einen gemeldeten Zeitraum von 28 Tagen Zugang
Aokigahara: Ein Infostealer sammelt Zugangsdaten von KI-Coding-Tools und Cloud-Schlüssel, schreibt Check Point Research

LiteLLM 1.107.0: Ein geleakter Master-Key wird zum Supply-Chain-Angriff

Was geschah: Am 27. Mai 2026 wurde ein Master-Key für die LiteLLM Agent Platform in ein öffentliches GitHub-Repository committet. Laut der Analyse der Angriffskette von LiteLLM wurde der Commit überschrieben, doch The Hacker News berichtet, dass der Schlüssel selbst nie widerrufen wurde. Am 10. Oktober las ein Angreifer damit ein GitHub-CLI-OAuth-Token aus, das einem Organisationsbesitzer gehörte. Laut LiteLLM waren die Berechtigungen des Tokens nicht eingeschränkt, sodass es jedes Repository der Organisation öffnete.

Anschließend pushte der Angreifer kurzlebige Workflows, die Repository-Secrets an einen externen Endpunkt sendeten. Socket zählt 20 verschiedene Secret-Namen in den wiederhergestellten Workflows vom 10. und 12. Oktober, von GitHub-Token bis zu Zugangsdaten für Anthropic, OpenAI und Datenbanken, und beziffert das Zeitfenster der Kompromittierung auf „mindestens elf Tage“ vor dem Release. Die eigene Zeitleiste von LiteLLM ist enger gefasst: Die erste Ausführung am 10. Oktober sendete sechs Secrets, darunter GH_TOKEN, die zweite sendete RELEASE_PLEASE_TOKEN, und spätere Ausführungen am 12. Oktober in privaten Repositories sendeten weitere.

Am 21. Oktober richtete der Angreifer die Release-Pipeline auf ein Doppelgänger-Repository aus: Berri-AI statt BerriAI. Laut The Hacker News war eine strengere Freigaberegel kurz zuvor gelockert worden, sodass zwei beliebige Entwickler ein Release auslösen und freigeben konnten. Den Rest erledigten gestohlene Token: Das Token des Besitzers löste das Release aus, das Token eines zweiten Maintainers (als GH_TOKEN gespeichert) gab die Produktionsfreigabe, und das eines dritten (RELEASE_PLEASE_TOKEN) löschte anschließend die Aufzeichnungen der Ausführungen. Sieben bösartige Wheels von LiteLLM 1.107.0 erreichten PyPI gegen 11:40 UTC, und die Analyse von Microsoft zeigt, dass die Payload beim Start von Python ausgeführt wurde, selbst wenn LiteLLM nie importiert wurde. Um 13:23 UTC hatte PyPI die Version unter Quarantäne gestellt, die Wheels waren also etwa 1 Stunde und 43 Minuten verfügbar.

Warum das wichtig ist: Der Stealer zielt auf Cloud- und Kubernetes-Zugangsdaten, Token für Git und Paket-Registries, SSH-Schlüssel, dotenv-Dateien, Browser-Zugangsdaten und die Konfiguration von KI-Tools. Wer 1.107.0 auf einem Host mit Internetzugang installiert hat, sollte davon ausgehen, dass alles, was dieser Host erreichen konnte, offengelegt ist. Microsoft stellt fest, dass das Entfernen des Pakets oder eines Release-Tags für eine Wiederherstellung nicht ausreicht, weil die Startdateien außerhalb des LiteLLM-Verzeichnisses liegen.

Konsequenz für die Abwehr: Beginnen Sie nicht mit pip install, denn jeder Python-Start führt die Payload erneut aus. Pinnen Sie die Version auf 1.106.2, wie LiteLLM empfiehlt. Suchen Sie in jeder Umgebung nach cook.pth und sitecustomize.py, außerdem nach cook.py, zugehörigen pycache-Dateien und dem abgekoppelten Loader, der /tmp/remote_code_loader.lock hält, und bauen Sie aus sauberen Images neu auf, statt an Ort und Stelle zu bereinigen. Rotieren Sie von einem sauberen Rechner aus alles, was der Host erreichen konnte, und prüfen Sie in CloudTrail, ob die Instanzrolle von außerhalb Ihrer Infrastruktur verwendet wurde. Die Erkenntnisse von Microsoft zu gestohlenem Sitzungsmaterial sprechen dafür, nicht nur Schlüssel, sondern auch Sitzungen zu widerrufen. Stellen Sie dann die schwierigere Frage: Wenn ein Secret in ein Repository gelangt, wer widerruft es, und wie stellen Sie sicher, dass es nicht mehr funktioniert?

Quellen: LiteLLM; Microsoft Security; Socket; The Hacker News; Vorfallsbericht von LiteLLM

Zeabur: Seit Januar 2024 nicht rotierte Admin-Token legen 321.810 Konten offen

Was geschah: Am 14. und 15. Oktober 2026 (UTC) nutzte ein Angreifer interne Zugangsdaten, die laut Zeabur im Klartext in einem privaten Konfigurations-Repository gespeichert waren; GCP-Root-Passwörter lagen in den Initialisierungseinstellungen der Server. Die Admin-Token der gemeinsam genutzten Cluster hatten kein Ablaufdatum, die Admin-Oberfläche war aus dem öffentlichen Internet erreichbar, und Zeabur hat nicht bestätigt, wie der Angreifer sie ursprünglich erlangte. Einen Zusammenhang mit dem Vorfall im August behandelt das Unternehmen als Hypothese. Der Angreifer las Umgebungsvariablen in den gemeinsam genutzten Clustern aus, meldete sich als Root an 101 dedizierten Servern auf GCP an, wovon 92 Benutzer betroffen waren, und las die Plattformdatenbank aus: laut dem Bericht von Zeabur 3.218.965 Datensätze mit Umgebungsvariablen und 321.810 Konten.

BleepingComputer berichtet, dass dies der zweite Sicherheitsvorfall bei der Plattform innerhalb von weniger als zwei Monaten war. Laut der Mitteilung von Zeabur zur Einstellung des Dienstes sind Verlängerungen dedizierter Server deaktiviert und gemeinsam genutzte Cluster ab dem 1. Dezember pausiert. Jeder dedizierte Server läuft zwischen dem 1. und dem 31. Dezember aus, und bis zum 31. Dezember wird alles abgeschaltet. Laut Zeabur erfasste die Rotation im August die diesmal verwendeten Zugangsdaten nicht. Die genannten Zahlen zeigen, was im Zugriffsbereich lag, und belegen nicht, dass jeder Wert heruntergeladen wurde; zudem sind die Logs laut Zeabur stellenweise unvollständig.

Warum das wichtig ist: Der Vorfall im August war die Warnung, und die anschließende Rotation blieb unvollständig. Zeabur meldet zudem mehr als 16 Stunden Angreiferaktivität am 14. Oktober, die keinen Alarm auslöste. Jede Umgebungsvariable auf der Plattform enthielt die eigenen Secrets eines Kunden, sodass aus einem einzigen Sicherheitsvorfall bei der Plattform Tausende nachgelagerte Leaks von Zugangsdaten wurden.

Konsequenz für die Abwehr: Die folgenden Schritte sind die Empfehlung von Passwork, nicht die von Zeabur: Erstellen Sie ein vollständiges Inventar aller Admin-Token und Cloud-Schlüssel, bevor Sie sie rotieren müssen. Versehen Sie jedes langlebige Token mit einem Ablaufdatum, machen Sie Admin-Oberflächen nicht aus dem öffentlichen Internet erreichbar und speichern Sie keine Zugangsdaten in Repositories oder Server-Initialisierungseinstellungen. Wenn Sie auf einer solchen Plattform hosten, betrachten Sie jede dort gespeicherte Variable als offengelegt und ersetzen Sie sie.

Quellen: Zeabur; BleepingComputer; Mitteilung von Zeabur zur Einstellung des Dienstes

Gheist: Gestohlene GitHub-Token machen CI-Workflows zu Secret-Sammlern

Was geschah: Wiz Research stellte mehr als 13.500 platzierte Branches aus 850+ kompromittierten GitHub-Konten sicher und benannte die Kampagne nach dem verwendeten User-Agent Gheist. Wiz begann am 15. September mit der Beobachtung und veröffentlichte die Ergebnisse am 25. Oktober, wie Help Net Security berichtet. Das Tool nimmt ein gestohlenes Token, ermittelt jedes Repository, das sich damit öffnen lässt, und pusht einen Branch namens „ci-sync-“ plus sechs Zeichen mit einem Workflow namens „sync-check“. Der Workflow gibt Repository-Secrets Base32-kodiert in ein Ausführungsprotokoll aus, eine Form, die die Log-Maskierung von GitHub nicht erkennt. Das Tool lädt das Protokoll über die API herunter und löscht die Ausführung Sekunden später, sodass Wiz keine Angreifer-Domain und keine ausgehende Verbindung fand, die sich hätte blockieren lassen. GitHub maskiert Secrets nur, wenn sie wörtlich erscheinen, weshalb die kodierten Werte vollständig ausgegeben werden.

Seit dem 28. Juli hält GitHub bestimmte potenziell bösartige Workflow-Ausführungen zur Freigabe zurück, allerdings nur in öffentlichen Repositories auf github.com. Laut Wiz gilt diese Sperre weder für private Repositories noch für GitHub Enterprise Server, und Wiz hat dort Ausnutzung beobachtet. In Unternehmensorganisationen sah Wiz, wie das Tool innerhalb von Minuten die Token mehrerer Benutzer und Automatisierungskonten durchlief. Stunden später wurden Cloud-Zugangsdaten derselben Organisation verwendet, um AWS Secrets Manager zu enumerieren. Wiz nennt die Organisationen nicht und gibt nicht an, wie viele betroffen waren.

Warum das wichtig ist: Ein einziges gestohlenes persönliches Token kann jedes Secret in jedem Repository offenlegen, das sein Besitzer erreichen kann, einschließlich umgebungsspezifischer Zugangsdaten für die Produktion. Das Löschen der Ausführung macht die Offenlegung nicht rückgängig.

Konsequenz für die Abwehr: Prüfen Sie das GitHub-Audit-Log auf den User-Agent „gheist“ und die Cloud-Logs auf OIDC-Rollenübernahmen, die mit „ci-sync-“-Branches verknüpft sind. Wiz empfiehlt, jedes Repository-, Organisations- und Umgebungs-Secret zu rotieren, das ein kompromittiertes Token erreichen konnte, und die Token selbst zu widerrufen. Das Branch-Signal funktioniert nur, wenn Ihr OIDC-Subject den Branch enthält. Beschränken Sie, welche Token Workflows pushen dürfen, und richten Sie Alarme für neue Workflow-Dateien in neuen Branches ein.

Quellen: Help Net Security; Wiz; GitHub-Changelog

PingCAP: Gestohlene Zugangsdaten, 28 Tage gemeldeter Zugriff

Was geschah: PingCAP berichtet, dass eine unbefugte Partei vom 9. September bis zum 7. Oktober 2026 gestohlene Zugangsdaten eines Dienstkontos nutzte, um auf interne Systeme zuzugreifen, Daten zu kopieren und Quellcode zu beschaffen. Das Unternehmen erfuhr am 7. Oktober davon und begann noch am selben Tag, die Zugangsdaten zu deaktivieren. Zu den offengelegten Daten gehören Konto- und Produktnutzungsdaten von TiDB Cloud, Vertrags- und Abrechnungsdetails sowie verschlüsselte API-Schlüsselwerte. Laut PingCAP gibt es keine Hinweise darauf, dass auf Daten in den TiDB-Datenbanken von Kunden zugegriffen wurde oder diese beeinträchtigt wurden. Kundenbezogene Datensätze in den internen Analyse-, Speicher- und Supportsystemen wurden jedoch kopiert, und das Unternehmen prüft noch, ob weitere verwendbare Zugangsdaten offengelegt wurden. Der Bericht vom 19. Oktober nennt nicht, wie die Zugangsdaten gestohlen wurden. Die CEO-Mitteilung von PingCAP vom 23. Oktober und die Analyse von NebuSec beschreiben den Erstzugang später als kompromittiertes GitHub-Konto und offengelegte Zugangsdaten. Beide geben zudem an, dass der Verschlüsselungsschlüssel für die exportierten API-Schlüsselwerte nicht offengelegt wurde, sodass sich diese nicht zu verwendbaren Schlüsseln entschlüsseln ließen. Das gilt nicht für Zugangsdaten, die Kunden in Supportunterlagen geteilt haben.

Warum das wichtig ist: Dienstkonten haben selten einen Verantwortlichen, ein Ablaufdatum oder eine Person, der ungewöhnliches Verhalten auffällt. Der gemeldete Zugriffszeitraum betrug 28 Tage, allerdings nicht unbedingt in Form einer einzigen ununterbrochenen Sitzung.

Konsequenz für die Abwehr: Geben Sie jedem Dienstkonto einen namentlich benannten Verantwortlichen, die geringsten Berechtigungen, mit denen es noch funktioniert, und ein Rotationsdatum. Richten Sie Alarme für ungewöhnlich große Exporte ein. PingCAP beschreibt eine umfassendere Rotation von Zugangsdaten, Zugriffsüberprüfungen und ein erweitertes Secret Scanning als laufende Arbeiten, was eine sinnvolle Vorlage für Ihre eigene Liste ergibt.

Quellen: PingCAP; CEO-Mitteilung von PingCAP; NebuSec

Aokigahara: Ein Infostealer, der es auf Zugangsdaten von KI-Coding-Tools abgesehen hat

Was geschah: Check Point Research dokumentiert (23. Oktober) einen Windows-Infostealer, den das Team Aokigahara nennt und der über einen eigenen Handler für Sitzungen von KI-Tools verfügt. Er sucht nach Dateien von Claude, Codex, Cursor, Windsurf, GitHub Copilot, Gemini CLI, Amazon Q, Kiro und JetBrains AI Assistant sowie nach AWS-Zugangsdaten und SSO-Caches. Sein IDE-Handler sammelt außerdem Dateien mit Git-Zugangsdaten, SSH-Dateien, die private Schlüssel enthalten können, sowie Zugangsdaten für Azure und Google Cloud. Ältere Funktionen bleiben erhalten: Browser-Passwörter und Cookies, Krypto-Wallets und Daten aus Passwort-Manager-Anwendungen. Der Bericht von Symantec vom 15. Oktober, über den das Infosecurity Magazine berichtete, identifiziert die Malware als Aoki (auch Aokigahara), die bereits früher im Jahr 2026 erstmals beobachtet wurde. Laut dem Bericht können gestohlene KI-Schlüssel weiterverkauft oder genutzt werden, um Kosten auf dem Konto eines Opfers zu verursachen, eine Praxis, die mitunter als LLMjacking bezeichnet wird.

Warum das wichtig ist: Auf einem Entwickler-Laptop liegen dieselben Zugangsdaten, die Angreifer gegen LiteLLM eingesetzt haben: Token, Cloud-Schlüssel und SSH-Schlüssel. Laut Check Point ließ sich nicht bestätigen, wie die Betreiber die Daten zu Geld machen; als Möglichkeiten nennt das Unternehmen Weiterverkauf, Missbrauch kostenpflichtiger Dienste und Erpressung. Die obigen Listen zeigen, was der Stealer sammelt, und sind kein Beleg dafür, dass die Daten jedes Opfers exfiltriert wurden.

Konsequenz für die Abwehr: Behandeln Sie Zugangsdaten und Sitzungsdateien von KI-Tools so sensibel wie Browser-Sitzungen, Cloud-Zugangsdaten und Entwicklerschlüssel, wie Check Point empfiehlt. Halten Sie langlebige Schlüssel nach Möglichkeit von Entwicklerrechnern fern, verwenden Sie kurzlebige Token und rotieren Sie schnell, wenn eine Workstation als auffällig gemeldet wird.

Quellen: Check Point Research; Symantec; Infosecurity Magazine

Was das für Ihr Team bedeutet

Jeder der obigen Fälle endet gleich: Zugangsdaten, die jemand für längst ungültig hielt, funktionierten noch. Sechs Prüfungen, die Sie jetzt durchführen sollten:

Bei Offenlegung widerrufen. Das Überschreiben eines Commits macht einen Schlüssel nicht ungültig. Betrachten Sie jedes Secret, das in ein Repository, ein Log oder einen Chat gelangt ist, als kompromittiert, und bestätigen Sie, dass der alte Wert nicht mehr funktioniert.
Jedes Token einschränken und befristen. Ersetzen Sie Token von Organisationsbesitzern durch eng gefasste, kurzlebige Token. Versehen Sie Admin- und Dienst-Token mit einem Ablaufdatum, damit ein Token aus dem Januar 2024 im Oktober 2026 nichts mehr öffnen kann.
Freigabeschritte beibehalten, die zwei gestohlene Token nicht erfüllen können. Die Release-Freigabe sollte von Identitäten und Geräten abhängen, die ein CI-Token nicht imitieren kann, und eine gelockerte Regel sollte eine Überprüfung auslösen.
CI-Secrets absichern. Bevorzugen Sie kurzlebigen Cloud-Zugriff gegenüber gespeicherten Schlüsseln, beschränken Sie, wer Workflows pushen darf, und richten Sie Alarme für neue Workflow-Dateien in neuen Branches ein, auch in privaten Repositories.
Entwicklerrechner und KI-Tool-Konfigurationen als Secret-Speicher behandeln. Erfassen Sie, was in dotenv-Dateien, SSH-Verzeichnissen und Sitzungen von KI-Assistenten liegt, und rotieren Sie nach einer Kompromittierung von einem sauberen Rechner aus.
Vollständig rotieren, nicht teilweise. Führen Sie ein Inventar aller Admin-Token und Cloud-Schlüssel, damit eine Rotation nach einem Vorfall alle davon abdeckt.

Wenn API-Schlüssel, Token und Zugangsdaten von Diensten noch in Konfigurationsdateien und Chatverläufen liegen, ist ihre Zusammenführung an einem Ort der erste Schritt, um sie planmäßig widerrufen zu können. Passwork speichert sie in verschlüsselten Tresoren mit rollenbasiertem Zugriff und einem Aktivitätsprotokoll, sodass Sie sehen, wer auf welches Secret zugreift, und es an einer einzigen Stelle rotieren. Passwork kostenlos testen.