GitHub Actions Re-Enabled With Mini Shai-Hulud Payload Still Active

New Research Pins Down Exactly How Long the Malware Stayed Live

CosmicBytez Labs reported last week that two GitHub Actions compromised in May's Mini Shai-Hulud campaign, actions-cool/issues-helper and actions-cool/maintain-one-comment, had quietly come back online and resumed executing their original malware. New reporting from BleepingComputer, built on research from application-security firm Socket, now fills in the details that were still murky at the time: the exact second-disable date, the technical mechanism that let the payload masquerade as a normal, successful workflow run, and a much larger blast radius than initially clear — Socket puts the number of repositories depending on issues-helper alone at roughly 15,000, pulled from GitHub's own dependency graph.

The short version: a maintainer or platform action restored public access to both repositories on September 16, 2026, without rewriting the malicious history from May. GitHub disabled them again on September 25, 2026 — after Socket's disclosure — meaning the reactivated payload was reachable by any workflow that referenced these actions by tag for roughly nine days.

Details

How the Payload Kept Its Cover

A wrapper, not a rewrite

Socket's analysis describes the malicious code as a wrapper sitting in front of the action's real logic rather than a replacement for it. A workflow step pulls in oven-sh/setup-bun to install the Bun JavaScript runtime, then runs bun run $GITHUB_ACTION_PATH/index.js — and that index.js contains an obfuscated payload. Because the wrapper executes first and then hands control back to the action's normal issue-housekeeping logic, the workflow step still completes and reports success. There's no failed build, no error in the logs — just a run that quietly took a few minutes longer than usual before doing the job it was supposed to do.

Socket flagged that behavior itself as a tell: an action whose entire purpose is closing stale issues and managing bot comments has no legitimate reason to install a separate JavaScript runtime and execute a multi-minute script before getting to work.

Tag pinning made the comeback possible

Neither action's release tags were repointed at clean commits when the repositories came back online — every tag, including v2.2.1, still resolved to the same malicious commit from May. Any organization that referenced these actions by version tag (the common, low-friction pattern: uses: actions-cool/issues-helper@v2.2.1) rather than a pinned commit SHA would have transparently re-downloaded and re-executed the same credential-stealing code on the next scheduled or triggered run — with zero new effort from the attackers. A workflow already pinned to a known-clean commit SHA predating May 18 was never affected by either the original compromise or the September re-enablement.

What the payload takes

Running inside a CI/CD job, the payload has access to whatever the workflow's GITHUB_TOKEN and repository secrets expose — commonly npm/PyPI publish tokens, cloud credentials, and internal API keys. That's consistent with the original May wave, which Socket says compromised 323 packages and 639 package versions on npm as part of the broader Mini Shai-Hulud cluster, targeting exactly this class of developer and CI/CD secret.

Why This Matters

• "Disabled" is not "remediated." GitHub (or the maintainer) suspending a compromised repository stopped the bleeding in May, but restoring access in September without auditing or rewriting the malicious history brought the exact same malware back online with no new attacker action required.
• Silent success is the danger. Because the wrapper structure lets the workflow step report success, teams monitoring only for failed CI runs would have had no signal that anything was wrong for over a week.
• Scale is larger than the two repos. With roughly 15,000 repositories depending on issues-helper through GitHub's dependency graph, the practical number of workflows that referenced it by a vulnerable tag — and therefore actually re-executed the payload between September 16 and 25 — is very likely in the thousands, even if not all 15,000 ran during that window.
• Convenience pinning is the root cause. Version-tag references (@v2.2.1) are popular precisely because they're easy to read and auto-update, but they hand a compromised or careless maintainer (or a platform restore action) the ability to change what code your CI actually runs, after the fact.

Recommendations

For teams using either action

1. Search every repository and branch for uses: actions-cool/issues-helper@ or uses: actions-cool/maintain-one-comment@ in .github/workflows/.
2. Remove the dependency if it isn't essential, or replace it with an alternative that has a clean, auditable history.
3. If continued use is unavoidable, pin to a commit SHA verified to predate May 18, 2026 — never a version tag — and re-review that commit's contents before trusting it.
4. Rotate every secret accessible to workflows that referenced either action between September 16 and 25, 2026: cloud credentials, npm/PyPI publish tokens, and internal API keys.
5. Audit run history for the specific indicators Socket published: unexpected use of oven-sh/setup-bun, a bun run $GITHUB_ACTION_PATH/index.js step, or run durations that jumped from seconds to multiple minutes without explanation.

For everyone using third-party GitHub Actions

1. Pin to commit SHA, not tag, as a standing policy — this is the single change that would have prevented both the May compromise and the September re-enablement from affecting a given workflow.
2. Treat a "repository restored" event as a new trust decision, not a return to the status quo — re-audit the code before resuming use of any action that was previously suspended for compromise.
3. Monitor for anomalous CI run durations as a cheap, high-signal detector for wrapper-style payloads that otherwise report success.
4. Consider tooling that alerts on changes to third-party Action dependencies, similar to how dependency-scanning tools already watch npm and other package registries.

Key Takeaways

1. actions-cool/issues-helper and actions-cool/maintain-one-comment, both compromised in the May 18, 2026 Mini Shai-Hulud wave, were restored on September 16, 2026 with their malicious release tags left untouched.
2. GitHub disabled both repositories a second time on September 25, 2026, after Socket's research went public — leaving the live payload reachable for roughly nine days.
3. The payload runs as a Bun-executed, obfuscated index.js that completes before handing off to the action's real logic, so infected workflow runs still report success.
4. Socket estimates roughly 15,000 repositories depend on issues-helper through GitHub's dependency graph, though not all necessarily ran during the exposure window.
5. Tag-based pinning (@v2.2.1) — not a code change — is what let the same May malware come back with zero new attacker effort; commit-SHA pinning would have prevented it entirely.
6. Anyone who used either action since September 16 should rotate exposed secrets and audit workflow run history immediately.

Related Reading

• Compromised GitHub Actions Came Back Online and Resumed Executing Mini Shai-Hulud Malware
• Shai-Hulud Attack: CrowdSec GitHub Data Stolen
• TeamPCP Ups the Game, Releases Shai-Hulud Worm's Source Code

Sources

• GitHub Actions re-enabled with Mini Shai-Hulud payload still active — BleepingComputer
• Re-Enabled GitHub Actions Expose Thousands of Repositories to Mini Shai-Hulud — Socket