Security3 publishers2 min readPublished Updated
Two actions-cool GitHub Actions resumed running the Mini Shai-Hulud stealer after coming back online
Two actions-cool GitHub Actions hijacked on May 18 came back online on September 16, still serving the Mini Shai-Hulud stealer to tag-pinned workflows. Only workflows pinned to a pre-May 18 commit SHA escaped; the rest have CI secrets to rotate.
The Watch · Security desk
What happened
- On May 18, 2026, two actions-cool GitHub Actions were altered to harvest credentials from the CI/CD pipelines that ran them and send them to an attacker-controlled server.
- Both repositories became accessible again on September 16, 2026, at some point between 11:09 and 18:16 GMT+2.
- Their release tags still pointed to the May 18 code, so any workflow referencing either action by version tag downloaded and ran the payload on its next run.
- GitHub Staff have since disabled both repositories again, citing a violation of GitHub's terms of service.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure Teams whose housekeeping workflows called either action by tag should treat every secret those jobs could read after September 16 as exposed, even though nobody on their side changed a line.
- constraint A takedown that leaves poisoned tags in place holds only while the repository stays disabled; restoring access restarts credential theft without any attacker action.
- decision Only full commit SHAs from before May 18 kept workflows clear; a version tag leaves every run dependent on whatever the upstream repository holds that day.
The attacker did nothing on September 16 [12]. "Most supply chain incidents involve something new: a newly published malicious version, a newly hijacked account, or a newly injected workflow," Socket researcher Karlo Zanki said. "This one did not. No new code was published and no configuration was changed." [16]
A workflow that calls an action by version tag fetches whatever that tag points to each time it runs [6]. Socket's guidance names actions-cool/[email protected] as affected [14]. It also tells teams to look in run history for workflows that started succeeding again after a prolonged period of Set up job failures, the trace a disabled action leaves behind [15].
Socket said the two actions handle housekeeping such as "closing inactive issues, checking newly opened ones, or keeping a single bot comment up to date" [11]. The workflows calling them "usually run on a daily schedule or whenever someone opens an issue or pull request," Socket said [12]. Its estimate is that "most affected repositories probably ran the payload within a day of the re-enablement, with no further action needed from the threat actor." [12]
The repositories came back 121 days after the May 18 compromise [18]. The time of the return is known only to within about seven hours [7][19]. The Hacker News reported that it is not known why the repositories became accessible again [8]. The report does not say when the second takedown happened or whether the exfiltration server was still receiving data [1].
Socket tied the May compromise to the Mini Shai-Hulud cluster through the exfiltration domain t.m-kosche[.]com, the same domain used in npm packages from the @antv ecosystem [4]. "That points to the same Mini Shai-Hulud activity cluster, not a separate npm-only incident," Philipp Burckhardt, Socket's head of threat intelligence, told The Hacker News at the time [5]. Nothing in the report shows the cluster doing anything new in September. The Hacker News describes no new exploit and no new infrastructure [10]. The malicious code was never cleaned out of the repositories, and making them downloadable again was enough to activate it [9].
"This incident shows that a mutable tag can be compromised, contained, and then reactivated without any change to your own workflow file," Zanki said [17]. Socket also advises auditing repository history for unexpected commits made after September 16 [15].
What to watch
- Whether the actions-cool release tags are rewritten or deleted before the repositories are ever restored again, or stay pointed at the May 18 code.
- Any explanation from GitHub of how a Staff-disabled repository was re-enabled on September 16 and what checks come before a restore.
- Reports of CI credentials taken during the September runs turning up in use, the first evidence of downstream impact from the reactivation.