GitHub Actions compromised in May came back online in September — malware payload still active

When GitHub's security team shut down two Actions repositories in May 2026, it looked like a clean takedown of a supply chain attack. The Mini Shai-Hulud campaign had compromised actions-cool/issues-helper and actions-cool/maintain-one-comment, injecting credential-stealing code into the index.js file. GitHub disabled both repos on May 19 — one day after the malicious code appeared — and the incident seemed closed.

It wasn't. On September 16, both repositories quietly came back online. Their release tags still pointed to the malicious code that had been there since May. GitHub had disabled access to the repos, but had not cleaned up the tags before re-enabling them. The result: every CI/CD workflow referencing either action by tag — rather than a pinned commit SHA — resumed downloading and executing the payload the next time it ran.

The two actions are used heavily for routine issue-housekeeping tasks: closing stale issues, adding labels, posting automated comments. That means they run frequently, often on a daily schedule. According to GitHub's own dependency graph, roughly 15,000 repositories depend on issues-helper alone — though not all pin to mutable tags, and the exact number of compromised workflow runs during the September 16–25 window hasn't been determined.

GitHub disabled both actions again on September 25, nine days after they had been re-enabled. The malware's primary target is developer credentials: OAuth tokens, CI/CD secrets, and access keys accessible to the workflow's environment.

What developers need to do now: If your workflows reference either action, audit all runs since September 16. Remove or replace references to both repos. Most importantly, rotate any secrets that were accessible during that period — access tokens, deploy keys, service account credentials, and anything else stored as a GitHub Actions secret or accessible from the environment.

The incident is a reminder of a persistent supply chain risk: re-enabling a repository without auditing its release tags can silently reactivate a threat that everyone assumed was neutralized. As The Hacker News reported, security researchers at SafeDep confirmed the payload was active and executing on affected repositories throughout the exposure window.