On September 16, two GitHub Actions repositories that GitHub had disabled four months earlier for distributing credential-stealing malware quietly became reachable again, and their malicious release tags were still pointing at the same compromised code.
What happened
The two repositories, actions-cool/issues-helper and actions-cool/maintain-one-comment, are small third-party GitHub Actions that automate routine repository chores: closing stale issues, keeping a bot comment current. According to security researcher Socket, both were compromised on May 18, 2026, when malicious code tied to the Mini Shai-Hulud campaign, a strain of the broader Shai-Hulud npm supply chain worm CyberTech has tracked since June, was pushed into their release tags. GitHub’s security team disabled both repositories the next day, May 19, cutting off downstream workflows from pulling the compromised code.
That fix held until September 16, when both repositories became accessible again sometime between 11:09 a.m. and 6:16 p.m. Central European time, for reasons Socket says remain unclear. The problem was that GitHub’s May takedown disabled the repositories themselves but never touched the malicious release tags already published inside them. Any workflow that referenced issues-helper or maintain-one-comment by a version tag, rather than by a pinned commit hash, resumed pulling and executing the same credential-harvesting payload the moment the repositories came back online, with no new attacker action required.
Media Partner
Socket reported the re-exposure on September 24 and updated its research the following day after GitHub disabled both repositories a second time, on September 25. In the meantime, GitHub’s own dependency graph lists roughly 15,000 repositories depending on issues-helper alone. Socket says it could not determine how many of those pull the action by a mutable tag rather than a fixed commit, which is the detail that decides whether a given repository was actually exposed during the nine day window.
Part of a pattern, not an isolated bug
This is the fourth Shai-Hulud family incident CyberTech has covered since June. The original worm compromised Red Hat’s own npm packages to steal cloud and vault credentials. A later variant added the ability to hunt for AI agent credentials across compromised systems. Days after that, a hijacked AI coding assistant was used as the delivery mechanism into more than 100 repositories. Most recently, a laptop compromised during the same May wave of attacks let someone quietly clone roughly 170 of CrowdSec’s private repositories, undiscovered until the stolen code surfaced on a criminal forum in September. Each incident is technically distinct, but all four share the same structural weakness: a credential or a dependency a team trusted once and then stopped watching.
A takedown that quietly reversed itself
The mechanism here is not exotic. GitHub Actions can be referenced two ways: by a mutable tag, such as @v3, which always resolves to whatever code currently sits at that tag, or by an immutable commit SHA, which resolves to one specific, unchangeable version of the code. Pinning to a tag is common, because it is convenient and because most maintainers assume a tag’s behavior only changes when the maintainer intentionally re-releases it.
That assumption is what failed here twice. First in May, when an attacker, not the legitimate maintainer, rewrote what the existing tags pointed to. Then again in September, when a repository-level control, GitHub disabling the account, was treated as equivalent to removing the malicious content, when it only removed the ability to fetch it. Once account access was restored, the same tags, still carrying the same malicious commits, were live again.
What it means for the security leader
The practical lesson is that a takedown notice or a disabled-repository banner is not the same claim as “the malicious code no longer exists,” and treating the two as interchangeable created a four month gap between incident and actual resolution that nobody was watching. CyberTech’s prior reporting on the Shai-Hulud family, including the variant hunting AI agent credentials and the CrowdSec incident where a four month old compromise surfaced only when stolen code appeared on a forum, points to the same pattern: a fix that looks complete at the moment of response can still leave load bearing assumptions unverified.
For a security team, the actionable version of that lesson is narrow and mechanical. A CI/CD dependency trusted enough to run unattended with a workflow’s secrets and tokens is trusted enough to warrant a specific, periodic check: does it still resolve to the commit last verified. Most organizations do not run that check, because most third party GitHub Actions were pinned once, at adoption, and never revisited.
What to do
Socket’s guidance, and CyberTech’s own read of the incident, points to the same four steps. Search workflows for any tag based reference to actions-cool/issues-helper or actions-cool/maintain-one-comment. Remove those actions, or repoint them to a commit SHA verified clean before May 18, 2026. Rotate every secret and token any affected workflow had access to, since the malicious payload was built to exfiltrate exactly those. And treat this specific fix as a template: audit every third party action still referenced by a mutable tag rather than a SHA, because this incident is the proof that “disabled” and “harmless” are not the same status. Any team that used either action between May 19 and September 16 was safe, since the repositories were offline; the window that matters is September 16 through September 25, when the tags were live again, so reviewing workflow run logs for that nine day span is the fastest way to know whether the payload actually executed rather than merely could have.
“A small, trusted piece of automation that nobody watches gives an attacker a lot of reach,” Socket security researcher Karlo Zanki wrote in the September 25 update to the firm’s research.
Source: Socket
