The actions-cool/issues-helper and actions-cool/maintain-one-comment actions were reactivated on GitHub on September 16, 2026, even though their release tags still pointed to a version containing a malicious payload associated with a supply-chain campaign called Mini Shai-Hulud. The two actions remained available until September 25, allowing workflows that invoked them through a release tag to download and execute the payload again.
GitHub’s security team had removed the two actions after they were compromised on May 18, preventing dependent workflows from downloading the malware. However, researchers at application security company Socket said the two repositories became available again on September 16 without first cleaning up the release tags. As a result, the tags continued to point to a software commit containing an obfuscated payload inside the index.js file.
What changed in practice?
Any workflow using either action through a mutable tag was exposed to a restoration of the previous behavior when it ran. The exposure window began on September 16 between 11:09 and 18:16 GMT+2. The presence of a repository in the dependency list does not mean it was automatically compromised; the risk depends, among other factors, on how the action was referenced and whether the workflow ran during the availability period.
GitHub’s dependency graph estimates that approximately 15,000 repositories depend on issues-helper, but the researchers did not determine how many projects use mutable tags instead of pinning the dependency to a specific software commit. The two actions are likely active in a large number of workflows that run nearly daily to automate issue-management tasks.
Why does this matter?
The Mini Shai-Hulud campaign targets developer tokens, credentials, and CI/CD environment secrets. Therefore, the impact of reactivating a compromised action is not limited to the machine that executes the workflow; it may also extend to the secrets made available to the workflow during the build or deployment. The incident shows that disabling a repository is insufficient if old tags return to operation before their contents are verified and cleaned up.
On September 25, Socket researchers found that the two actions had been disabled again on GitHub, causing workflows that invoked them to fail instead of executing the payload. The reason the two repositories were reactivated without proper prior cleanup was not clear.
Recommended actions
- Search for all references to the two actions and remove them, or pin them to a trusted, clean, verified commit.
- Review workflow runs since September 16, focusing on workflows that used the affected release tags.
- Rotate secrets that were available to any workflow that ran either action during the exposure period.
The available data points to an incident limited to a specific time period, but they do not establish how many projects actually executed the payload. The exact reason for the reavailability and the number of dependencies that used mutable tags also remain unresolved.