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.
Why it matters
- Who's exposed 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.
- What it limits 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.
- Who has to decide 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.
Next story · Build · yesterday
GhostAction's secret-stealing workflows reached 30,000 repos through hijacked developer accounts, researchers sayConfirmed2 publishers
The attacker did nothing on September 16 [19]. "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." [8]
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/issues-helper@v2.2.1 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" [12]. The workflows calling them "usually run on a daily schedule or whenever someone opens an issue or pull request," Socket said [19]. 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." [19]
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 [9][17]. The Hacker News reported that it is not known why the repositories became accessible again [10]. 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 [11]. The malicious code was never cleaned out of the repositories, and making them downloadable again was enough to activate it [7].
"This incident shows that a mutable tag can be compromised, contained, and then reactivated without any change to your own workflow file," Zanki said [16]. 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.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence60
- Adoption40
- Hype gap+15
- Incentives30
- Confidence65
Perspective Coverage
3 publishers- Builder
- Builder 43%
- Operator
- Operator 47%
- Investor
- Investor 10%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Two actions-cool GitHub Actions have been disabled for a second time after the repositories became accessible last week, months after they were compromised during the May 2026 Mini Shai-Hulud campaign.
- [2]
Visiting either repository shows the message: "Access to this repository has been disabled by GitHub Staff due to a violation of GitHub's terms of service. If you are the owner of the repository, you may reach out to GitHub Support for more information."
- [3]
The two GitHub Actions were originally compromised on May 18, 2026, to run malicious code that harvested sensitive credentials from the CI/CD pipelines that ran them and exfiltrated the details to an attacker-controlled server.
- [4]
The activity was linked to the Mini Shai-Hulud activity cluster, citing overlaps in the exfiltration domain t.m-kosche[.]com used in the GitHub Actions workflows and the npm packages from the @antv ecosystem.
- [5]
"That points to the same Mini Shai-Hulud activity cluster, not a separate npm-only incident."
- [6]
"On September 16, 2026, both repositories became accessible again. Their release tags were not cleaned up first. They still point to the malicious content introduced on May 18, so any workflow that references either action by a version tag resumed downloading and executing the payload on its next run."
- [7]
The malicious code remained in the affected codebases and was never cleaned up; all that was required to activate the threat was for the repositories to become downloadable again.
- [8]
"Most supply chain incidents involve something new: a newly published malicious version, a newly hijacked account, or a newly injected workflow. This one did not. No new code was published and no configuration was changed."
- [9]
The repositories were re-enabled on September 16, 2026, at some point between 11:09 a.m. and 6:16 p.m. GMT+2.
- [10]
It is currently not known why the repositories were re-enabled.
- [11]
Several workflows still use the two GitHub Actions, and the exposure could have led to software supply chain risks without the threat actors needing a new exploit or new infrastructure.
- [12]
"Both actions automate issue and comment housekeeping, such as closing inactive issues, checking newly opened ones, or keeping a single bot comment up to date."
- [13]
The issue does not impact workflows that pin either action to the full commit SHA of a version from before May 18, 2026.
- [14]
Developers are advised to locate every reference to the affected actions, treat actions-cool/issues-helper@v2.2.1 as affected, and remove the actions and pin them to a known-clean SHA that predates May 18, 2026.
- [15]
Developers are advised to rotate all exposed secrets, review workflow run history for newly successful runs after a prolonged period of Set up job failures, and audit repository history for unexpected commits after September 16, 2026.
- [16]
"This incident shows that a mutable tag can be compromised, contained, and then reactivated without any change to your own workflow file. SHA pinning removes that dependency on the upstream repository's state."
- [17]
The re-enablement window on September 16 spans about seven hours (7 hours 7 minutes).
- [18]
The repositories became accessible again 121 days after the May 18, 2026 compromise.
- [19]
"The workflows that call them usually run on a daily schedule or whenever someone opens an issue or pull request. In practice, most affected repositories probably ran the payload within a day of the re-enablement, with no further action needed from the threat actor."
Sources
2 independent publishers whose own reporting we read for this story.
- bleepingcomputer.comGitHub Actions re-enabled with Mini Shai-Hulud payload still active
2 articles · September 26, 2026
- scworld.comCompromised GitHub Actions re-enabled, posing supply chain risks
1 article · September 25, 2026
- thehackernews.comCompromised GitHub Actions Came Back Online and Resumed Executing Mini Shai-Hulud Malware
2 articles · September 26, 2026
Topics and entities
Entities
- actions-cool/maintain-one-comment
- Philipp Burckhardt
- Mini Shai-Hulud
- actions-cool/issues-helper
- Karlo Zanki
- npm registry
- GitHub
- GitHub Actions
- Socket