A GitHub Actions Worm GitHub 'Fixed' in May Came Back Online in September and Reinfected Everyone Still Pinning by Tag
Two GitHub Actions, actions-cool/issues-helper and actions-cool/maintain-one-comment, were compromised on May 18 with an obfuscated "Mini Shai-Hulud" payload and disabled by GitHub the next day. That should have been the end of it. Instead, when GitHub re-enabled both repositories on September 16, the malicious release tags were still pointing at the same poisoned code, and every workflow that referenced those tags automatically started re-executing the payload on its next run. The attacker didn't have to do anything new. GitHub's own fix, undone by GitHub's own re-enablement, did the work for them.
How a fixed vulnerability came back with zero new effort
The root cause is how GitHub Actions resolves version references. If your workflow pins an action to a tag like @v2.2.1 instead of a commit SHA, that tag is mutable. Whatever code the tag points to right now is what runs, not whatever code it pointed to when you first added the dependency. When the two actions-cool repositories were disabled in May, their malicious tags weren't cleaned up, just frozen in place along with the repos. On September 16, between 11:09 and 18:16 GMT+2, GitHub re-enabled both repositories, and the tags came back exactly as compromised as they'd been in May. Any workflow with a scheduled run, or one triggered by an issue or pull request, resumed downloading and executing the same payload automatically. Socket's research team estimates issues-helper alone has roughly 15,000 downstream dependents, and because these actions typically run on daily schedules or common repo events, most affected repositories likely executed the payload within a day of the re-enablement. GitHub disabled both actions again on September 25.
The ten-minute check
You don't need to audit your entire dependency tree for this one. Open a terminal in each of your repositories and search:
grep -rn "actions-cool/issues-helper@\|actions-cool/maintain-one-comment@" .github/workflows/
If you get a match, look at what comes after the @. If it's a version tag rather than a 40-character commit hash, you were exposed between September 16 and September 25, full stop, regardless of whether you noticed anything unusual. Replace the reference with the full commit SHA of a release you've personally verified predates May 18, 2026, or just remove the action if you can live without it. Then rotate any secrets that workflow had access to (repository tokens, deploy keys, anything in secrets.* referenced in the same job), and check your runner logs for bun run $GITHUB_ACTION_PATH/index.js executing around those dates, which is the signature Socket's writeup points to for the payload's entry point.
Why "it's just a comment bot" isn't a reason to skip this
Both compromised actions are the kind of low-stakes-looking dependency nobody thinks twice about: one auto-manages issue labels and comments, the other maintains a single pinned comment on a PR. That's exactly the profile that makes them dangerous. A comment-bot action gets added once, runs on a schedule or on every issue event, and then nobody looks at it again for years, which is precisely long enough for its maintainer's account to get compromised, a malicious release to slip through, and the whole thing to get "fixed" by GitHub without you ever knowing you were affected in the first place.
The honest gap in the fix
Pinning by commit SHA instead of tag is the correct long-term answer, and it's also more annoying to maintain: you lose the convenience of automatically picking up patch releases, and you have to manually bump the SHA every time you actually want an update. That tradeoff is why so many workflows still pin by tag despite years of security advice telling people not to. I don't think "just pin by SHA" fully solves this either. GitHub re-enabling a repository without first scrubbing or invalidating its compromised tags is a process failure on GitHub's side, not just a hygiene failure on the part of individual maintainers, and that's worth saying plainly instead of only handing out advice that puts the burden entirely on the smallest player in the chain.
What I'd actually do
Run the grep above right now, on every repo you maintain, not just your main one. If you find a hit, fix it today, this isn't a "get to it eventually" item given the exposure window already closed once and could reopen the same way. Then set a recurring reminder, monthly is enough, to spot-check your .github/workflows/ directories for any action still pinned by tag, because this exact failure mode (a disabled repo re-enabled with its poison intact) can happen to any compromised action GitHub has ever "fixed," not just these two.
Author
Lukas
@lukcombinator