GitHub Switched Two Compromised Actions Back On — and the Malware Tags Were Still There
On May 18, actions-cool/issues-helper and actions-cool/maintain-one-comment — two widely used GitHub Actions for issue and comment housekeeping — were compromised to run code that harvested credentials from the CI/CD pipelines that executed them and exfiltrated the loot to an attacker-controlled server. GitHub disabled both repositories. That should have been the end of it. According to Socket, whose researchers reported the sequel to The Hacker News on September 25, both repositories became accessible again on September 16 — with the malicious release tags still pointing at the May payload. Every workflow pinning either action by version tag resumed downloading and executing credential-stealing code on its next run.
The attacker did nothing. That is the story.
Contained, then reactivated, with zero attacker effort
Socket researcher Karlo Zanki puts the timeline precisely: the repositories came back online on September 16 at some point between 11:09 a.m. and 6:16 p.m. GMT+2, and “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.” Why the repositories were re-enabled is not known. What matters is that the malicious code was never removed from the codebase — reactivation alone was sufficient, because the tags are mutable references that still resolved to the poisoned commits.
Both actions automate routine chores — closing inactive issues, triaging newly opened ones, keeping a single bot comment current — and the workflows that call them typically run on daily schedules or on every issue and pull-request event. Socket’s assessment is blunt: most affected repositories probably executed the payload within a day of re-enablement, with no further action needed from the threat actor. GitHub has since disabled both repositories a second time; visiting either now returns the standard terms-of-service violation notice.
Same cluster, same infrastructure
The May compromise was attributed to the Mini Shai-Hulud activity cluster on the strength of a shared exfiltration domain, t.m-kosche[.]com, appearing both in the poisoned Actions workflows and in malicious @antv npm packages — “not a separate npm-only incident,” as Socket’s head of threat intelligence Philipp Burckhardt told The Hacker News at the time. We covered that campaign in May in our writeup of the TeamPCP operation across npm, GitHub Actions, and VS Code. The September reactivation therefore re-armed an already-attributed credential-theft pipeline rather than starting a new one — and any secrets harvested this time flow to infrastructure the defenders have known about for four months.
The finding is about mutable tags, not about these two repos
Zanki’s framing deserves quoting directly, because it generalises beyond actions-cool: “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.” The incident demonstrates that a mutable tag can be compromised, contained, and then reactivated without a single change to the victim’s workflow file. Tag-based pinning is a standing bet that the upstream repository’s state will only ever change in benign ways — and this month that bet lost after the fact, on code that had already been flagged, quarantined, and forgotten.
Workflows pinned to the full commit SHA of a pre–May 18 version were never exposed, which is the entire argument for SHA pinning in one incident. The related lesson from our own recent coverage cuts the other way and is worth holding alongside it: SHA pinning itself can be bypassed when the pinned reference is resolved through a confusable layer. Pin by hash, but verify what the hash resolves to.
What to do
- Treat
actions-cool/issues-helper@v2.2.1as affected. Locate every reference to both actions across your organisations, remove them or re-pin to a known-clean commit SHA predating May 18, 2026. - Rotate every secret visible to those workflows. The payload’s purpose was credential theft from the runner environment — assume
GITHUB_TOKEN-adjacent secrets, cloud credentials, and publish tokens that were present in runs after September 16 are burned. The MemTensor sckit worm showed days ago how fast CI-harvested tokens get monetised. - Review workflow run history for resurrections. Look for runs that newly succeeded after a prolonged period of failures on any workflow referencing these actions — a job that suddenly goes green after four months of failing is the signature of this reactivation.
- Audit repository history after September 16. These actions hold write-capable tokens by design; check for unexpected commits, label changes, or comment edits the reanimated workflows may have made while they were alive.
- Make SHA pinning the default for third-party Actions, and monitor the pins. A tag is a promise from someone else’s infrastructure. Pin the hash, and alert when the tag moves underneath it.
Sources: