Die Actions actions-cool/issues-helper und actions-cool/maintain-one-comment wurden am 16. September 2026 auf GitHub erneut aktiviert, obwohl ihre Release-Tags weiterhin auf eine Version mit einer bösartigen Payload verwiesen, die mit einer Lieferkettenkampagne namens Mini Shai-Hulud verbunden war. Die beiden Actions blieben bis zum 25. September verfügbar, wodurch Workflows, die sie über ein Release-Tag aufriefen, die Payload erneut herunterladen und ausführen konnten.
Das GitHub-Sicherheitsteam hatte die beiden Actions nach ihrer Kompromittierung am 18. Mai entfernt, wodurch abhängige Workflows daran gehindert wurden, die Schadsoftware herunterzuladen. Forscher des Anwendungssicherheitsunternehmens Socket erklärten jedoch, dass die beiden Repositorys am 16. September wieder verfügbar wurden, ohne zuvor die Release-Tags zu bereinigen. Infolgedessen verwiesen die Tags weiterhin auf einen Commit, der eine verschleierte Payload in der Datei index.js enthielt.
Was hat sich praktisch geändert?
Jeder Workflow, der eine der beiden Actions über ein veränderliches Tag verwendete, war bei seiner Ausführung dem Risiko ausgesetzt, das vorherige Verhalten wieder aufzunehmen. Das Expositionsfenster begann am 16. September zwischen 11:09 und 18:16 Uhr GMT+2. Dass ein Repository in der Abhängigkeitsliste enthalten ist, bedeutet nicht automatisch, dass es kompromittiert wurde; das Risiko hängt unter anderem davon ab, wie auf die Action verwiesen wird und ob der Workflow während des Zeitraums ihrer Verfügbarkeit ausgeführt wurde.
GitHubs Abhängigkeitskarte schätzt, dass etwa 15.000 Repositorys von issues-helper abhängen. Die Forscher haben jedoch nicht ermittelt, wie viele Projekte veränderliche Tags statt einer Festlegung der Abhängigkeit auf einen bestimmten Commit verwenden. Es ist wahrscheinlich, dass die beiden Actions in einer großen Zahl von Workflows aktiv sind, die fast täglich zur Automatisierung von Aufgaben der Problemverwaltung ausgeführt werden.
Warum ist diese Nachricht wichtig?
Die Kampagne Mini Shai-Hulud zielt auf Entwicklertoken, Zugangsdaten und Geheimnisse in CI/CD-Umgebungen ab. Daher beschränkt sich die Auswirkung der erneuten Aktivierung einer kompromittierten Action nicht auf das Gerät, auf dem der Workflow ausgeführt wird, sondern kann sich auch auf die Geheimnisse erstrecken, die der Workflow während des Builds oder der Bereitstellung zugänglich macht. Der Vorfall zeigt, dass die Deaktivierung eines Repositorys nicht ausreicht, wenn alte Tags wieder aktiviert werden, bevor ihr Inhalt überprüft und bereinigt wurde.
Am 25. September stellten die Socket-Forscher fest, dass die beiden Actions auf GitHub erneut deaktiviert worden waren. Daraufhin schlugen Workflows, die sie aufriefen, fehl, anstatt die Payload auszuführen. Der Grund für die erneute Aktivierung der beiden Repositorys ohne vorherige angemessene Bereinigung blieb unklar.
Empfohlene Maßnahmen
- Nach allen Verweisen auf die beiden Actions suchen und diese entfernen oder auf einen überprüften, vertrauenswürdigen und sauberen Commit festlegen.
- Ausführungen von Workflows seit dem 16. September überprüfen, wobei der Schwerpunkt auf Workflows liegen sollte, die die betroffenen Release-Tags verwendet haben.
- Geheimnisse rotieren, die jedem Workflow zugänglich waren, der während des Expositionszeitraums eine der beiden Actions ausgeführt hat.
Die verfügbaren Daten weisen auf einen zeitlich begrenzten Vorfall hin, belegen jedoch nicht, in wie vielen Projekten die Payload tatsächlich ausgeführt wurde. Auch der genaue Grund für die erneute Verfügbarkeit und die Zahl der Abhängigkeiten, die veränderliche Tags verwendet haben, sind weiterhin ungeklärt.