"On September 16, 2026, both repositories became accessible again," Socket researcher Karlo Zanki said.
Timeline: May compromise, September re‑enablement
Two actions-cool GitHub Actions that had been taken offline after a May 2026 compromise were available again on September 16, 2026. The repositories were re-enabled on that day at some point between 11:09 a.m. and 6:16 p.m. GMT+2, according to Socket. When a search or direct visit to either repository now occurs, visitors see 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."
How the malicious payload resumed: uncleaned release tags and mutable version tags
Socket researcher Karlo Zanki reported that the repositories' release tags were not cleaned up before the repositories became downloadable again. Those tags still pointed to malicious content that had been introduced on May 18, 2026, so "any workflow that references either action by a version tag resumed downloading and executing the payload on its next run." Zanki emphasized the mechanism: "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."
Nobody's watching your logs at 2 AM.
Full SOC coverage without building one. Nubivance deploys and manages Rapid7 InsightIDR and MDR for organizations that need detection and response, not another dashboard.
Get coverageWhat the injected code did and the link to Mini Shai-Hulud
The two GitHub Actions workflows were altered on May 18, 2026, to run code that harvested sensitive credentials from CI/CD pipelines and exfiltrated those details to an attacker-controlled server. Socket analysts tied that activity to the Mini Shai-Hulud cluster, in part because the exfiltration domain used in the GitHub Actions workflows — "t.m-kosche[.]com" — overlapped with domains used by malicious 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.
Operational exposure: routine workflows, wide reach
Both actions in question automate routine issue and comment housekeeping — closing inactive issues, checking newly opened ones, and keeping a single bot comment up to date, Socket said. Workflows that call them typically 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," Socket observed. Because the malicious code remained in the codebases and required no new published version or fresh infrastructure, the exposure could have led to severe software supply chain security risks simply by making the repositories downloadable again.
Recommended remediation steps for developers and repository owners
The published guidance for developers and maintainers is concrete and procedural. The advice includes:
- 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.
Socket noted that workflows which already pin an action to the full commit SHA of a version from before May 18, 2026, are not impacted by this specific re‑enablement.
What this means for technologists, maintainers, and enterprises
Technologists and security teams should immediately search CI/CD configurations for references to the two actions and inspect recent workflow runs for unexpected successful executions after the September 16 window; they should rotate any secrets that could have been exposed. Maintainers of open-source projects that used the actions should audit repository history for commits after September 16 and replace mutable version tags with SHA pins predating May 18, 2026. Enterprises that rely on third-party actions in automated workflows should treat this incident as an example of how a contained compromise can be reactivated without a new exploit and thus should verify pinning practices and run‑history anomalies across their fleets.
This episode underscores a narrow but consequential operational reality: a mutable tag that was compromised months earlier remained capable of reactivating a supply chain infection simply because the repository became downloadable again. It also raises a specific unresolved question in the record provided: why the repositories were re-enabled on September 16 and why release tags pointing at malicious content were not cleaned before re-enablement. Until that is answered, the safe course for teams that consume third-party actions is to assume any mutable tag that passed through the affected window may be unsafe and to prefer immutable SHA pinning.
