Two GitHub Actions came back online for nine days with live malware

A restoration with no cleanup first

On 18 May, two third-party actions — actions-cool/issues-helper and actions-cool/maintain-one-comment — were compromised as part of the Mini Shai-Hulud campaign. GitHub’s security team removed both repositories, which mechanically stopped any downstream workflow from downloading the booby-trapped code.

According to researchers at application security firm Socket, the two repositories became reachable again on 16 September 2026, in a window between 11:09 and 18:16 GMT+2. They came back with their original version tags, and those tags had not been cleaned: they still resolved to the 18 May commit, whose index.js file contains the obfuscated payload. Why the repositories were re-enabled without that cleanup is not known at this stage. The story was reported on 26 September by Bleeping Computer, based on Socket’s work.

A version tag is a pointer, not a fingerprint

That distinction is the whole mechanism of this incident. A workflow that references an action by version tag is not asking for specific content: it is asking for whatever that tag points to at run time. While the repository was taken down, resolution failed and nothing executed. Once the repository was back, the very same line of YAML, untouched for months, went straight back to downloading and running May’s code on the next run.

A workflow that pins a verified commit instead of a tag is not affected: a commit hash does not move. Socket says it has not yet established what share of the dependents use one form or the other.

Around 15,000 dependent repositories, an unknown victim count

GitHub’s dependency graph lists roughly 15,000 repositories depending on issues-helper. That number does not tell you how many actually executed the payload: it counts declared dependents, not runs.

Two factors cut the other way, though. Both actions are used for issue housekeeping, a job that runs close to daily: across nine days, an affected repository had several chances to trigger the payload. And the payload targets exactly what a CI runner has within reach. May’s Mini Shai-Hulud campaign hit 323 packages and 639 package versions on the npm index, with malware going after developers’ CI/CD tokens, credentials and secrets.

What to check if you are affected

On 25 September, Socket observed that both actions were disabled on GitHub again: workflows referencing them now fail rather than running the payload. The exposure window is therefore closed, but it does not clean up after itself.

Socket’s recommendations come down to four points: search your workflows for references to the two actions, remove them or pin them to a clean verified commit, review any runs from 16 September onwards, and rotate the secrets that were available to workflows using an affected tag.

That last item is the most expensive and the least avoidable: a secret readable by a suspect run has to be treated as exposed until something proves otherwise. Taking a malicious repository down protects its dependents immediately; putting it back without cleaning its tags restarts the attack on them, with not a single line of their configuration having changed.