Wiederhergestellte GitHub-Actions-Repositories ließen ruhende Supply-Chain-Schadsoftware kurzzeitig wieder aufleben

Wiederhergestellter Repository-Zugriff erweckte alten Schadcode wieder zum Leben

Zwei von actions-cool gepflegte GitHub Actions waren am 16. September 2026 kurzzeitig wieder erreichbar. Dadurch wurde schädlicher Code reaktiviert, der nach der Mini-Shai-Hulud-Kampagne zurückgeblieben war.

Betroffen waren folgende Repositories:

• actions-cool/issues-helper
• actions-cool/maintain-one-comment

Beide waren ursprünglich am 18. Mai 2026 kompromittiert worden. Die Release-Tags wurden nach dem Vorfall nie vollständig bereinigt und verwiesen weiterhin auf von Angreifern veränderte Inhalte.

Als der Zugriff auf die Repositories wieder möglich war, konnten Workflows, die von diesen veränderlichen Versions-Tags abhingen, die Payload erneut herunterladen und ausführen. Die Nutzer mussten ihre Workflow-Dateien dafür nicht ändern, und die Angreifer mussten auch kein weiteres Release veröffentlichen.

Der Socket-Forscher Karlo Zanki zufolge waren die Repositories am 16. September zwischen 11:09 Uhr und 18:16 Uhr GMT+2 verfügbar. Anschließend wurden sie erneut deaktiviert.

Laut einer Mitteilung von GitHub hatte das Unternehmen den Zugriff wegen eines Verstoßes gegen die Nutzungsbedingungen gesperrt. Warum die Repositories wieder freigeschaltet wurden und welcher Prozess dazu führte, dass zuvor schädliche Referenzen erneut heruntergeladen werden konnten, ist nicht bekannt.

Veränderliche Tags machten aus der Wiederherstellung eine Ausführung

GitHub-Actions-Workflows können Automatisierungen von Drittanbietern über Referenzen wie diese einbinden:

uses: actions-cool/[email protected]

Die Referenz hinter dem @ kann einen Versions-Tag statt eines unveränderlichen Commits bezeichnen. Ein Tag kann weiterhin auf kompromittierte Inhalte verweisen – oder auf andere Inhalte umgeleitet werden –, ohne dass der nachgelagerte Workflow geändert wird.

Genau dieser Unterschied war für den Vorfall entscheidend. Sobald GitHub den Zugriff auf die actions-cool-Repositories wiederhergestellt hatte, konnten Runner die vorhandenen Tags auflösen und den bereits im Upstream gespeicherten Schadcode abrufen.

Die Referenz actions-cool/[email protected] muss als kompromittiert behandelt werden. Für actions-cool/maintain-one-comment wurde keine konkrete betroffene Version genannt. Unternehmen sollten daher jede Verwendung dieser Action untersuchen und nicht davon ausgehen, dass ein bestimmter Tag sicher ist.

Es waren weder die Veröffentlichung neuen Codes noch Änderungen an der Workflow-Konfiguration, ein Exploit oder eine vom Angreifer kontrollierte Infrastruktur erforderlich. Die bloße Verfügbarkeit der Repositories reaktivierte den Verbreitungsweg.

Workflows, die auf die vollständige Commit-SHA einer nachweislich sauberen Version vor dem 18. Mai 2026 festgelegt waren, waren nicht betroffen. Anders als ein veränderlicher Tag bindet eine vollständige Commit-Hash die Abhängigkeit an einen bestimmten Repository-Stand.

Automatisierte Routineaufgaben boten häufige Ausführungsgelegenheiten

Die kompromittierten Actions übernehmen gängige Aufgaben der Repository-Pflege. Dazu gehören die Prüfung neu erstellter Issues, das Schließen inaktiver Issues und die Aktualisierung eines einzelnen automatisierten Kommentars.

Solche Jobs werden oft täglich oder bei bestimmten Aktivitäten ausgeführt, etwa wenn ein neues Issue oder ein Pull Request erstellt wird. Dadurch ergaben sich während des siebenstündigen Verfügbarkeitsfensters mehrere Gelegenheiten, bei denen die wiederhergestellten Repositories CI/CD-Runner erreichen konnten.

Socket schätzt, dass viele abhängige Repositories die Payload innerhalb eines Tages nach der Wiederherstellung der Actions ausgeführt haben könnten. Weitere Aktivitäten der Angreifer wären dafür nicht nötig gewesen.

Der Schadcode versuchte, im CI/CD-Umfeld verfügbare Zugangsdaten abzugreifen und an einen von den Angreifern kontrollierten Server zu senden. Der bekannte Exfiltrationsindikator lautet:

t.m-kosche[.]com

Alle Repositories, in denen während des relevanten Zeitraums eine der beiden Actions ausgeführt wurde, sollten daher auf eine mögliche Offenlegung von Secrets untersucht werden. Die potenziellen Folgen reichen über den einzelnen Workflow hinaus, da gestohlene Zugangsdaten Zugriff auf Repositories, Build-Systeme oder Software-Veröffentlichungsprozesse ermöglichen können.

Welche konkreten Zugangsdaten aus den einzelnen betroffenen Umgebungen abgegriffen wurden, ist nicht bekannt. Ob es zu einer Offenlegung kam, hängt davon ab, welche Secrets und Berechtigungen dem Job bei der Ausführung der kompromittierten Action zur Verfügung standen.

Hinweise verknüpfen die Aktivitäten mit Mini Shai-Hulud

Der Vorfall wird dem Aktivitätscluster Mini Shai-Hulud zugeordnet, zu dem auch npm-Pakete aus dem @antv-Ökosystem gehörten.

Philipp Burckhardt, Leiter der Abteilung Threat Intelligence bei Socket, kam zu dem Schluss, dass die gemeinsame Exfiltrations-Domain die Kompromittierung der GitHub Actions und die npm-Aktivitäten mit demselben Cluster verbindet. Seiner Einschätzung nach gab es aufgrund dieser Überschneidung keinen Anlass, den npm-Vorfall als separaten Vorfall zu betrachten.

Entscheidend war hier die Persistenz in der Software-Lieferkette: Die Inhalte der Angreifer blieben hinter Referenzen erhalten, denen nachgelagerte Repositories bereits vertrauten. Durch die Deaktivierung der Upstream-Repositories wurde die Auslieferung zwar unterbrochen, die kompromittierten Objekte wurden dadurch aber nicht entfernt.

Mit der Wiederherstellung der Verfügbarkeit wurde daher auch der Angriffsweg wiederhergestellt. Bestehende Workflow-Konfigurationen wurden erneut gefährlich, obwohl sie unverändert geblieben waren.

Repository-Verantwortliche sollten Secrets rotieren und Ausführungsverläufe prüfen

Verantwortliche sollten zunächst alle Workflow-Dateien nach Referenzen auf die beiden betroffenen Actions durchsuchen. Dazu zählen auch wiederverwendbare Workflows und ältere Branches, in denen Automatisierungen noch ausgelöst werden können.

Mindestens sollten Incident-Response-Teams folgende Maßnahmen ergreifen:

1. actions-cool/[email protected] als kompromittiert behandeln.
2. Beide actions-cool-Abhängigkeiten entfernen oder durch eine verifizierte vollständige Commit-SHA ersetzen, die auf einen Stand vor dem 18. Mai 2026 verweist.
3. Alle Secrets rotieren, die den betroffenen Workflow-Jobs möglicherweise zur Verfügung standen.
4. Den Verlauf der Workflow-Ausführungen auf erfolgreiche Runs nach einer längeren Folge von Fehlern bei Set up job prüfen.
5. Runs untersuchen, die in das Verfügbarkeitsfenster am 16. September 2026 fallen.
6. Den Repository-Verlauf auf unerwartete Commits nach dem 16. September 2026 prüfen.
7. Netzwerk-, Proxy- und CI/CD-Telemetriedaten nach Verbindungen zu t.m-kosche[.]com durchsuchen.

Die Rotation sollte sich nicht auf Zugangsdaten beschränken, deren Diebstahl bereits bestätigt wurde. Wenn ein Token, Schlüssel oder Passwort für einen Job verfügbar war, der die schädliche Action erfolgreich geladen hat, sollten Verantwortliche von einer Offenlegung ausgehen – es sei denn, Ausführungsdaten belegen das Gegenteil.

Repository-Verantwortliche sollten außerdem die Berechtigungen der Workflow-Tokens überprüfen. Die Folgen eines Diebstahls hängen maßgeblich davon ab, ob die Tokens lediglich Quellcode lesen oder auch Repositories und zugehörige Release-Prozesse ändern konnten.

Das Festschreiben auf Commit-SHAs begrenzt das Risiko reaktivierter Abhängigkeiten

Der Vorfall verdeutlicht eine konkrete Schwachstelle von GitHub-Actions-Abhängigkeiten, die auf Tags basieren: Das Vertrauen hängt weiterhin vom veränderlichen Zustand eines externen Repositories ab.

Ein Workflow mit der Referenz @v2.2.1 mag festgelegt erscheinen, doch ein Tag ist kein unveränderliches Software-Artefakt. Seine Sicherheit kann sich ändern, wenn das Upstream-Repository verändert, kompromittiert, entfernt oder wiederhergestellt wird.

Das Festschreiben von Drittanbieter-Actions auf vollständige Commit-SHAs verringert dieses Risiko, weil der Workflow damit eine ganz bestimmte Revision anfordert. Unternehmen müssen den ausgewählten Commit weiterhin verifizieren und Sicherheitsvorfälle bei Upstream-Anbietern beobachten. Eine Wiederherstellung des Repositorys kann die festgeschriebene Referenz jedoch nicht unbemerkt auf anderen Code umlenken.

Zugriffsbeschränkungen und Deaktivierungen bleiben sinnvolle Maßnahmen zur Eindämmung eines Vorfalls. Sie beseitigen jedoch keine schädlichen Inhalte, die hinter vertrauenswürdigen Release-Tags weiterhin vorhanden sind.