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.
The affected GitHub Actions are listed below –
Visiting either of the repositories now 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.”
“On September 16, 2026, both repositories became accessible again,” Socket researcher Karlo Zanki said. “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.”
The two GitHub Actions workflows were originally compromised on May 18, 2026, to run malicious code that harvested sensitive credentials from CI/CD pipelines that ran them and exfiltrated the details to an attacker-controlled server.
The activity was subsequently 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.
“That points to the same Mini Shai-Hulud activity cluster, not a separate npm-only incident,” Philipp Burckhardt, head of threat intelligence at Socket, told The Hacker News at the time.
The repositories were re-enabled on September 16, 2026, at some point between 11:09 a.m. and 6:16 p.m. GMT+2. It’s currently not known why this occurred.
But the latest development points to another problem: the malicious code remained in the affected codebases and never cleaned up, and all that was required to activate the threat was for the repositories to become downloadable again.
Given that there are still several workflows that use the two GitHub Actions, the exposure could have led to severe software supply chain security risks without the need for the threat actors to use a new exploit or set up new infrastructure.
“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,” Socket said.
“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.”
The issue does not impact workflows that pin either action to the full commit SHA of a version from before May 18, 2026. Developers are recommended to carry out the following steps –
- Locate every reference to the affected actions and treat “actions-cool/issues-helper@v2.2.1” as affected.
- Remove the actions and pin them to a known-clean SHA that predates May 18, 2026.
- Rotate all exposed secrets.
- Review workflow run history and check for newly successful runs after a prolonged period of Set up job failures.
- Audit repository history for unexpected commits after September 16, 2026.
“Most supply chain incidents involve something new: a newly published malicious version, a newly hijacked account, or a newly injected workflow,” Zanki said. “This one did not. No new code was published and no configuration was changed.”
“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.”
