# The Actions Came Back. The May Tags Were Still Dirty. > Socket says two actions-cool GitHub Actions, disabled on 19 May after Mini Shai-Hulud, became downloadable again on 16 September with those May tags still malicious. Workflows that name a tag, not a commit, resumed running that code until GitHub disabled both repositories on 25 September. A graph of about 15,000 dependents is not an infection count. Source: https://hackerlogs.com/blog/actions-cool-tags-came-back Published: 2026-09-27 ## Key takeaways - Socket's primary is actions-cool/issues-helper and actions-cool/maintain-one-comment. Malicious tags landed on 18 May. GitHub disabled both repositories on 19 May. The tags were never cleaned. - On 16 September, between 09:09 and 16:16 UTC, both repositories were reachable again. Jobs that had failed in seconds started succeeding and running for minutes. - GitHub's dependency graph lists about 15,000 repositories on issues-helper. Socket has not counted how many name a mutable tag instead of a commit SHA. - On 25 September both repositories were disabled again. A tag reference was exposed for that whole window. A pin to a clean commit from before 18 May was not. - Socket does not know why the repositories came back. A maintainer request is a guess, not a finding. Treat a second disable as containment, not as a cleaned tag. On 16 September two GitHub Actions that had been disabled since 19 May became downloadable again, and their release tags still pointed at Mini Shai-Hulud content from 18 May. [Socket](https://socket.dev/blog/mini-shai-hulud-actions), written by Karlo Zanki, is the primary. GitHub disabled both repositories a second time on 25 September. Disable was the containment. It was not a deletion of the tags. US X trends on 27 September were NFL games and celebrity names. Hacker News did not lead with this. The Hacker News, BleepingComputer, and Socket did. A housekeeping action ran again with the workflow token and any secret that job could see. High because the next scheduled run was enough, not because 15,000 repositories are confirmed owned. Three panels for the actions-cool re-enable: May tags still malicious when the repositories came back on 16 September, a dependency graph that is not an infection count, and a second disable on 25 September that does not retire stolen tokens. ## What Socket actually saw. The two actions are `actions-cool/issues-helper` and `actions-cool/maintain-one-comment`. They close stale issues, look at new ones, and keep a bot comment current. They do not ship in a product. They still run on a schedule, or when someone opens an issue or a pull request, inside the runner, with that workflow's `GITHUB_TOKEN` and whatever secrets the workflow exposes. The May compromise moved what the release tags resolved to. GitHub's security team disabled both repositories on 19 May, one day later. While a repository is disabled, the runner fails during setup, before action code runs. Socket's archived capture of the issues-helper tags page from 19 May shows the usual notice that access was disabled. The malicious tags stayed in the repositories the whole time. On 16 September the same tags resolved again. Socket's example is a "Close Inactive Issue" run. Run 1849 died in about two seconds at "Repository access blocked." The next run, 1850, took 11 minutes and 25 seconds and downloaded `actions-cool/issues-helper` at `v2.2.1`, which resolved to commit `a0c53dd42fc842d2f9276c5a1d4f9a26abe8713d`. A daily "Issue Inactive" workflow on `Moonofweisheng/wot-design-uni` failed in seconds on 14 and 15 September, then succeeded at 16:16 UTC on 16 September and ran for 9 minutes and 34 seconds. Nobody edited those workflow files. The dependency became fetchable. > A disabled repository is a gate on download. It does not rewrite tags, releases, or the default branch. Socket's point is that the May content was still what the tags named when the gate opened. A workflow you did not touch executed different bytes because the platform's containment was temporary. ## The package clock and the impact clock. The package clock is the tag, and it barely moved. Malicious content on 18 May. Disable on 19 May. No new version, no new commit you had to merge, no new account takeover in September. The tags were dirty on the way out and dirty on the way back. The impact clock is the window when download worked. Socket bounds the re-enable to 16 September, between 09:09 and 16:16 UTC. It does not know the exact minute. Both actions came back together, so the same window covers `maintain-one-comment`. These workflows usually run daily or on an issue event. Socket's judgment is that most affected repositories probably ran the code within a day of the re-enable, with no further action from the actor. Anyone who can open an issue on a public repo can fire an issue-triggered job. On 25 September Socket found both repositories disabled again. Workflows that still name them now fail at job setup instead of running the May content. That closes the package clock a second time. It does not close a secret a successful run already reached. [The Hacker News](https://thehackernews.com/2026/09/compromised-github-actions-came-back.html) ties the May tags to the Mini Shai-Hulud cluster. The September event did not need a new payload. It needed the old tags to be fetchable. > About 15,000 is not a victim count. It is GitHub's dependency graph for `issues-helper` alone, with `maintain-one-comment` on top. Socket has not counted tag references versus SHA pins. A code search for `uses: actions-cool/issues-helper@v` in workflow files returns many tag pins. "Many" is the bound. Do not brief leadership with 15,000 owned repos. ## What this is not. It is not a new package publish, and it is not a rewrite of the [TanStack token](/blog/tanstack-token-lasted-months). That brief is the May npm worm and a stolen CI token that was still live in September. This one is a platform disable that expired while the git tags stayed malicious. It is not proof the maintainer flipped the switch. Socket lists a maintainer request as a possibility. BleepingComputer states it as what happened. Use Socket until someone shows the audit log. It is not a pass for SHA pins that point at the May commit. Pinning protects you only when the pinned commit is clean and predates 18 May. Pinning the malicious commit on purpose is the incident, frozen. It is not an Actions outage you can ignore because the jobs fail again now. Failure after 25 September is the second gate. Success between 16 and 25 September is the impact clock. ## What to do. 1. Search every repository you own for `actions-cool/issues-helper@` and `actions-cool/maintain-one-comment@` under `.github/workflows/`. Treat a tag, including `v2.2.1`, as in scope. A full SHA from before 18 May is the exception, and only after you confirm that commit. 2. Remove the actions, or replace the tag with a commit you have verified from before 18 May. Do this even though the repositories are disabled again. The next re-enable will not send you a diff. 3. For any job that ran a tag reference on or after 16 September, rotate every secret that workflow could read, and review what `GITHUB_TOKEN` was allowed to do. A green job that used to fail in two seconds is the signal. Duration jumping from seconds to minutes is the same signal. 4. Read run history from 16 September through 25 September. Then look for commits you cannot account for after 16 September. Socket's recommendation stops there. It does not require you to reproduce the May code. 5. Pin every other third-party action to a full commit SHA. A mutable tag can be compromised, contained, and reactivated without a change in your workflow file. That is the control this window actually tested. 6. If you own a registry or a forge, do not treat "disabled" as remediation for a poisoned tag. Before access returns, tags, releases, and the default branch have to stop naming the bad content. Downstream jobs will resolve them on the next schedule. The Hacker News front page on 27 September was not this. The operator fact is the tag. For about nine days the May bytes were a normal dependency again, and the workflow file did not have to change for that to happen. ## Sources - [Re-Enabled GitHub Actions Expose Thousands of Repositories to Mini Shai-Hulud](https://socket.dev/blog/mini-shai-hulud-actions) (2026-09-24) - [Compromised GitHub Actions Came Back Online and Resumed Executing Mini Shai-Hulud Malware](https://thehackernews.com/2026/09/compromised-github-actions-came-back.html) (2026-09-25) - [GitHub Actions re-enabled with Mini Shai-Hulud payload still active](https://www.bleepingcomputer.com/news/security/github-actions-re-enabled-with-mini-shai-hulud-payload-still-active/) (2026-09-26)