Two GitHub Actions hit by Mini Shai-Hulud re-enabled with their payload still live
The actions-cool/issues-helper and maintain-one-comment actions, compromised on 18 May 2026 in the Mini Shai-Hulud campaign, were re-enabled on 16 September with tags still pointing at malicious code, according to Socket. The lesson is blunt: in CI/CD, a mutable tag is a door left open.
18 May 2026. Two third-party GitHub Actions, actions-cool/issues-helper and actions-cool/maintain-one-comment, are compromised in the Mini Shai-Hulud campaign. 323 npm packages. That is the scale of the supply-chain attack that went after developers’ tokens and secrets. 16 September 2026. Both actions are re-enabled by their maintainer, with version tags still pointing at the malicious code. Why it matters: for nine days, workflows could download and run the old payload, and nobody noticed.
What the incident timeline shows
The story begins on 18 May 2026. The two actions in the actions-cool repository — utilities for automating issues on GitHub — are compromised. GitHub’s security team pulls them from the registry, blocking any downstream workflow from downloading the malware. The cleanup looks complete.
Except that on 16 September 2026, both repositories become accessible again. The version tags, however, were not cleaned up: they still point at the 18 May commit, the one containing the obfuscated payload inside the index.js file. The direct consequence, described by Socket researchers, is that any workflow referencing either action by a mutable tag resumed downloading and executing the payload on its next run.
On 25 September 2026, Socket reports that both actions were disabled again on GitHub. The exposure window, meanwhile, ran from 16 September between 11:09 and 18:16 through to 25 September — more than a week during which the malicious payload was once again available.
Mini Shai-Hulud: a supply-chain attack spanning 323 packages
The Mini Shai-Hulud campaign, disclosed in May 2026, is one of the broadest recent supply-chain attacks on the npm ecosystem. It infected 323 packages and 639 versions on the Node Package Manager registry, injecting malware designed to steal developers’ tokens, credentials, and CI/CD secrets.
The vector for the two compromised actions is the same: a maintainer account taken over, a repository modified, then version tags reassigned to point at malicious code. The issues-helper action is widely used: GitHub lists roughly 15,000 repositories depending on it, though that figure does not mean all were compromised — it depends on how each workflow references the action.
What made the re-enabling dangerous is the reference mechanism. A workflow that writes uses: actions-cool/issues-helper@v1 does not point at frozen code but at a mutable tag: if the tag is reassigned, the code that runs changes without the workflow file being touched. That is exactly what happened.
Why a mutable tag is an open door
The difference between pinning an action to a tag and pinning it to a commit is the difference between a pointer and a fingerprint. A tag like @v1 can be moved at any time by whoever holds the repository — or whoever compromised it. A commit SHA, by contrast, identifies immutable content: if the code changes, the SHA changes, and the workflow fails instead of running unknown code.
Socket’s recommendation is unambiguous. Find every reference to the two actions, remove them or pin them to a verified clean commit, then review runs since 16 September and rotate secrets accessible to workflows that ran an affected tag.
The check requires no exotic tooling. Two commands are enough to surface the risky references in a repository:
# References to the compromised actions (handle first)
grep -rn "actions-cool/issues-helper\|actions-cool/maintain-one-comment" .github/
# References by mutable tag (replace with a commit SHA)
grep -rn "uses: .*@v[0-9]" .github/workflows/The deeper lesson: supply chain is decided at execution time
This incident illustrates a reality that security teams repeat without always being heard: the software supply chain is no longer limited to library dependencies; it now extends to the CI/CD actions that run with a project’s secrets. A workflow that downloads a compromised action does not only compromise the build machine: it exposes everything the workflow could read — deployment tokens, keys, registry credentials.
The re-enabling of the two actions adds a layer of worry. The initial takedown by GitHub in May suggested the problem was closed. The reappearance in September, with no prior cleanup of the tags, shows that remediation is as fragile as detection: a repository hastily re-enabled can reopen a breach everyone thought sealed.
Socket has not established how many dependent repositories reference the actions by mutable tag rather than a pinned commit. But the profile of the actions — issue-housekeeping utilities that run almost daily — means many affected workflows run regularly, and therefore many could have re-executed the payload during the exposure window.
An npm ecosystem under pressure, repeat offenders included
The re-enabling of the two actions does not happen in a vacuum. The npm ecosystem has been under sustained pressure on its supply chain for months. The Mini Shai-Hulud campaign of May 2026 is only one link in a series: forged GitHub repositories pushing infostealers like Rapuncel, fake LastPass installers abusing signed drivers, malicious packages evading defenses at install time. The common thread is that these attacks target the developer’s tooling rather than the final application: whoever controls the pipeline controls everything that comes out of it.
What makes the two-actions incident instructive is the repeat offense. A May compromise was remediated, then reopened in September because the fix never touched the root of the problem: the tags. Cleaning a compromised repository is not limited to removing malicious code from HEAD. It also means purging the tag history, reassigning versions to clean commits, and checking that nothing still points at the payload. Failing that, simply re-enabling a repository puts the malware back into circulation.
The practical recommendation comes down to three moves. First, pin every action to a commit SHA instead of a tag. Second, audit pipeline dependencies regularly, not just application code dependencies. Third, treat CI/CD secrets as what they are: production credentials, subject to rotation and least privilege, not environment variables left lying in a config file. A workflow should never be able to read more than it needs to run.
Small teams are not exempt. The actions in question are the kind of free utilities that a solo maintainer adds to automate issue triage, not enterprise tooling. Their very ubiquity is what made them a target: an attacker needs only one widely used action to reach thousands of repositories. The defense, fortunately, scales the same way — pinning one commit protects every workflow that references it. The cost of pinning is a few minutes of one-time work; the cost of ignoring it can be a production secret in the wrong hands, and by then the cleanup is measured in days, not minutes.
Verdict
If your organization uses GitHub Actions, run an inventory of third-party actions referenced by mutable tag without delay, start with the two compromised actions, and pin every action to a verified commit SHA. If a workflow ran an affected tag between 16 and 25 September, rotate the secrets it could read, no exceptions: an unrotated secret is a secret presumed stolen. If you maintain a public action, the lesson is yours too: a version tag is a contract of trust, and re-enabling it without verifying it is a failure. Supply-chain security is not declared once: it is verified at every execution.