GitHub restored two hijacked Actions without fixing the tags
Two Actions poisoned in the May Mini Shai-Hulud attack came back online in September with the malicious tags untouched, so tag-pinned workflows ran the payload again.
Two GitHub Actions compromised in May’s Mini Shai-Hulud supply-chain attack, actions-cool/issues-helper and actions-cool/maintain-one-comment, came back online on 16 September with their poisoned release tags never reverted. Research published by SafeDep on 24 September found the attacker had hijacked 53 and 15 version tags respectively back in May, pointing them at commits that steal CI secrets and tokens. GitHub pulled both repositories down at the time, but when it restored them in September nobody fixed the tags first, so any workflow that referenced the actions by version, such as @v2.1.1 or @v3, resumed downloading and running the payload on its next run.
GitHub’s own dependency graph lists roughly 15,000 repositories depending on issues-helper alone. GitHub disabled both actions again on 25 September, which stops new runs but does nothing to undo whatever a workflow already leaked during the nine days the repositories were live.
Why it matters: pinning a GitHub Action to a version tag means trusting that the tag will always point where it did when you first wrote the workflow. Tags can move, and in this case even the platform’s own remediation reopened a hole it had already closed. Pin to a commit SHA instead:
- uses: actions-cool/issues-helper@a1b2c3d4e5f6 # commit SHA, not @v3The caveat: disabling the actions again on 25 September closes the immediate risk, but only for workflows that haven’t already run against the poisoned tags. If your CI history covers 16 to 25 September, check the logs for these two actions specifically.