Two GitHub Actions compromised in May were switched back on with the malicious code still inside

Two GitHub Actions compromised in May were switched back on with the malicious code still inside

25 September 2026 — Two third-party GitHub Actions that were taken down in May after being hijacked in the "Mini Shai-Hulud" supply-chain campaign became usable again on 16 September 2026, with their release tags still pointing at the malicious code. The security firm Socket found the problem and reported it; both actions were disabled again on 25 September. For nine days, any workflow that called either action by a version tag downloaded and ran the payload again.

What happened

The two actions are actions-cool/issues-helper and actions-cool/maintain-one-comment, small helpers that projects use to label, comment on and close issues and pull requests automatically. According to Socket, malicious code was added to both on 18 May 2026 and GitHub's security team disabled the repositories. BleepingComputer gives 18 May for the disabling as well; Socket gives 19 May. The sources agree on what matters: both were off from May until 16 September, when Socket says they were re-enabled some time between 11:09 and 18:16 (GMT+2).

Socket says the tags were never cleaned, so re-enabling the repositories put the compromised versions straight back into circulation. It describes the payload as installing the Bun JavaScript runtime and running a script, the same pattern it documented in May. GitHub's dependency graph lists about 15,000 repositories depending on issues-helper; how many of those were exposed depends on whether they reference a mutable tag, which was exposed, or a pinned commit SHA, which was not.

Neither source reports a statement from GitHub on why the repositories were re-enabled.

Who is affected

Any organisation whose GitHub workflows use either action, directly or through a reusable workflow or template copied from another project. Workflows that run on pull requests or with access to deployment keys, package-registry tokens or cloud credentials are the serious case: supply-chain payloads of this kind typically look for exactly those secrets. Software suppliers and agencies that build on GitHub for clients are in scope too, since a secret stolen from their pipeline can reach a customer's systems.

What to do

• Search every repository and organisation-level workflow for actions-cool/issues-helper and actions-cool/maintain-one-comment, including reusable workflows and templates.
• Remove them, or replace the tag with a commit SHA you have verified as clean.
• Review workflow runs from 16 to 25 September for either action. Where one ran, treat every secret available to that workflow as exposed and rotate it: repository and organisation secrets, cloud keys, registry tokens and deploy keys.
• Check for unexpected commits, new workflow files, releases or packages published from affected repositories in that window.
• Pin all third-party actions to full commit SHAs, and consider an allow-list of approved actions at organisation level, so a re-enabled or re-tagged action cannot change what runs in your pipeline.
• If a supplier builds software for you on GitHub, ask it in writing whether either action ran in its pipelines between 16 and 25 September.

Sources

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