Mini Shai-Hulud actions re-enabled: pin to commit SHAs

Two compromised GitHub Actions came back online on September 16 with the malware still inside them. actions-cool/issues-helper and actions-cool/maintain-one-comment were pulled in May after the Mini Shai-Hulud campaign injected credential-harvesting code into both. Somebody re-enabled the repositories without cleaning the release tags first, so every workflow that referenced them by tag quietly started running the payload again. They stayed up for nine days.

What actually happened

Per Socket's research and reporting from BleepingComputer:

• The original compromise was May 18, 2026. GitHub's security team disabled both repositories on May 19 — one day later. That part worked.
• Both came back on September 16, sometime between 09:09 and 16:16 UTC. Every release tag still resolved to malicious content. The v2.2.1 tag of issues-helper points at commit a0c53dd42fc842d2f9276c5a1d4f9a26abe8713d.
• They were disabled again on September 25. That is a nine-day window in which a tag-pinned workflow executed attacker code.
• Roughly 15,000 repositories depend on issues-helper according to GitHub's dependency graph. Both actions do issue and comment housekeeping, which means they fire on issue events, PR events, or a daily cron. Socket's read is that most affected repos ran the payload within about a day.
• The blast radius is your secrets. These actions run with the workflow's GITHUB_TOKEN and anything else that workflow exposes. BleepingComputer puts the original May campaign at 323 npm packages across 639 package versions.

Why mutable action references matter for your business

There is no new exploit here. The vulnerability is a pointer. @v2.2.1 is a label someone else can move, and a disable-list is a control someone else can undo. Your build pulled a tarball, the tarball changed, and nothing in your diff, your review, or your changelog said a word about it.

That is the uncomfortable part for a small team: your remediation in May was somebody else's takedown action, and it expired without telling you. If your only defense against a compromised dependency is that the platform deleted it, you are one accidental re-enable away from running the payload a second time.

Three things to do today. Grep every workflow for actions-cool/ — both actions, every ref. Rotate every secret reachable by those workflows since September 16, including GITHUB_TOKEN-derived credentials, npm tokens, cloud keys, and deploy keys. Then check run history for duration jumps on jobs that normally finish in seconds; a run that suddenly takes minutes is worth opening.

The durable fix is boring and you already know it: pin every third-party action to a full 40-character commit SHA, and let Dependabot propose the bumps. A SHA is a fact. A tag is a promise.

Sources: Socket: Re-Enabled GitHub Actions Expose Thousands of Repositories to Mini Shai-Hulud, BleepingComputer.