// hackerlogs
login+ register
Supply ChainLLM AppSecThreat BriefHigh

The Actions Came Back. The May Tags Were Still Dirty.

Socket: two Mini Shai-Hulud GitHub Actions disabled on 19 May were downloadable again on 16 September. Tags were still malicious. Disabled again on 25 September.

Ajain Vivek · Editor, hackerlogs5 min readPractitioner

The short answer

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.

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, 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.

High 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.

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 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.

  1. Malicious content introduced on both actions. Release tags point at it. The Hacker News later ties that May change to Mini Shai-Hulud.
  2. GitHub disables both repositories. Downstream jobs fail at setup. The tags are not cleaned.
  3. Both reachable again between 09:09 and 16:16 UTC. Tag-based workflows that had been failing in seconds start succeeding.
  4. Socket publishes. Zanki: no new code and no configuration change. The repositories were simply downloadable again.
  5. Socket's update: both disabled again. Referencing workflows fail at setup. The Hacker News reports the second disable the same day.
  6. BleepingComputer writes that the maintainer re-enabled the repos. Socket still says that cause is unconfirmed.

What this is not.#

It is not a new package publish, and it is not a rewrite of the TanStack token. 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.

Frequently asked

If GitHub disabled the actions again, is the incident over?

The download stopped. The impact did not. From 16 September until the second disable on 25 September, a workflow that named either action by tag could fetch the May content on its next run. Rotate secrets that those jobs could see, and review runs that flipped from a seconds-long setup failure to a multi-minute success. A later disable does not expire a token that already left.

Does a version tag like v2.2.1 pin the code?

No. In GitHub Actions that string is a movable tag. Socket logged issues-helper v2.2.1 resolving to the May content once the repository was reachable again. Only a full commit SHA stays put, and only if that commit itself predates 18 May and you have checked it.

Are all 15,000 dependents compromised?

No. That figure is GitHub's dependency graph for issues-helper, plus more repos on maintain-one-comment. Socket has not measured how many of those references are tags rather than SHAs. A repo that never ran during the window, or that pinned a clean commit, is not in the same bucket as one whose scheduled job succeeded on 16 September.

Who turned the repositories back on?

Socket says it could not tell. A request from the legitimate maintainers is one possibility, and Socket had not confirmed it. BleepingComputer wrote that the maintainer re-enabled them. That is a stronger claim than the primary. Hunt your runs either way. The actor did not need a new publish for the tags to execute again.

Sources

Related