Die Wiederfreischaltung erfolgte ohne vorherige Bereinigung der Release-Tags – genau darin liegt das Problem. „Am 16. September 2026 wurden beide Repositories wieder zugänglich. Ihre Release-Tags wurden zuvor nicht bereinigt“, erklärte Socket. „Sie verweisen weiterhin auf die am 18. Mai eingeschleusten bösartigen Inhalte, sodass jeder Workflow, der eine der beiden Actions über ein Versions-Tag referenziert, beim nächsten Lauf erneut die Schadfunktion heruntergeladen und ausgeführt hat.“
Die Socket-Forscher stellten fest, dass die Release-Tags von actions-cool/issues-helper und actions-cool/maintain-one-comment auf einen Commit aufgelöst wurden, der in der Datei „index.js“ eine verschleierte Schadfunktion enthielt. Der Zeitraum der Exposition begann demnach am 16. September zwischen 11:09 und 18:16 Uhr (GMT+2).
Zum möglichen Ausmaß verweist Socket auf den Abhängigkeitsgraphen von GitHub: Dort sind rund 15.000 Repositories gelistet, die von „issues-helper“ abhängen. Das bedeutet jedoch nicht, dass all diese Projekte kompromittiert wurden. Wie viele Abhängigkeiten die Actions über ein veränderliches Tag statt über einen festgepinnten Commit einbinden, konnten die Forscher bislang nicht ermitteln.
Besonders relevant ist nach Einschätzung der Forscher, dass die betroffenen Actions praktisch täglich laufen, da sie Aufgaben rund um die Pflege von Issues übernehmen. Entsprechend häufig dürften Workflows die manipulierten Tags in dem fraglichen Zeitraum abgerufen haben.
Die ursprüngliche Kampagne aus dem Mai traf 323 Pakete und 639 Paketversionen im npm-Index. Die dort eingeschleuste Schadsoftware zielt auf Tokens, Zugangsdaten und CI/CD-Geheimnisse von Entwicklern – also genau jene Werte, auf die auch Workflows in GitHub Actions typischerweise Zugriff haben.
Am 25. September waren beide Actions auf GitHub laut Socket wieder deaktiviert. Workflows, die sie referenzieren, schlagen seitdem fehl, statt die Schadfunktion auszuführen.
Socket empfiehlt betroffenen Entwicklerteams, im eigenen Bestand nach Verweisen auf die beiden Actions zu suchen und diese entweder zu entfernen oder auf einen verifiziert sauberen Commit festzupinnen. Zusätzlich sollten alle Läufe seit dem 16. September überprüft und sämtliche Geheimnisse rotiert werden, auf die Workflows Zugriff hatten, in denen ein betroffenes Tag ausgeführt wurde.