Two compromised GitHub Actions from the actions-cool project were disabled a second time after spending more than a week reachable again with their malicious release tags intact. In May 2026, during the Mini Shai-Hulud supply chain campaign, the first two to be taken down were actions-cool/issues-helper and actions-cool/maintain-one-comment; on September 16, 2026, from 11:09 a.m. to 6:16 p.m., access to them was restored. GMT+2.

Visiting either repository now returns a notice that access has been disabled by GitHub Staff for a terms-of-service violation, with a pointer to GitHub Support for owners. According to Socket researcher Karlo Zanki, the release tags remained unchanged when the repositories returned online, continuing to point to the malicious content added on May 18. As a result, any workflow using a version tag to reference either action automatically started fetching and running the payload during its next execution.

That is the uncomfortable part of this story. No new malicious version was published, no account was freshly hijacked, and no workflow file was edited. The compromise simply sat in the tags, waiting for the repository to become downloadable again.

What the payload did

The two actions automate issue and comment housekeeping — closing inactive issues, checking newly opened ones, and keeping a single bot comment current. Because these workflows usually trigger on a daily basis or when an issue or pull request is opened, most impacted repositories likely ran the payload within a day of the repositories becoming accessible, without requiring any new action by the threat actor.

The code harvested sensitive credentials from the CI/CD pipelines that ran it and sent the details to an attacker-controlled server. The May activity was linked to the Mini Shai-Hulud cluster through overlaps in the exfiltration domain t.m-kosche[.]com, also seen in malicious npm packages from the @antv ecosystem. Philipp Burckhardt, head of threat intelligence at Socket, described that overlap as pointing to the same activity cluster rather than a separate npm-only incident.

Scale is the reason this matters. Socket says GitHub's dependency graph lists roughly 15,000 repositories depending on issues-helper, though that figure does not mean all of them were compromised. The researchers have not determined how many dependent projects use a mutable tag rather than a pinned commit to reference either action, meaning only those tag-based workflows were at risk.

Why the re-enablement happened is still open

It remains unclear why the repositories became accessible again without the tags being cleaned first. The window ran from September 16 until September 25, when Socket found both actions disabled once more — this time causing workflows that reference them to fail rather than run the payload.

Actions pinned to the full commit SHA of a version released before May 18, 2026, remain safe from this specific payload. That distinction is the whole lesson here: a tag is a pointer that can be re-pointed, while a commit SHA is immutable.

In its remediation guidance, Socket tells developers to find each reference to the affected actions — with actions-cool/[email protected] counted as affected — then either delete those references or pin them to a known-clean SHA from before May 18, 2026, and rotate every secret exposed to workflows that ran an affected tag. It also recommends reviewing workflow run history for newly successful runs after a long stretch of Set up job failures, and auditing repository history for unexpected commits after September 16, 2026.

Zanki framed the incident as a departure from the usual pattern. In most supply chain incidents, what is involved is something new — a malicious version just published, an account hijacked just now, or a workflow injected only recently. This one involved none of those. Compromise, containment, and reactivation can all happen to a mutable tag while a downstream workflow file stays unchanged; this is why SHA pinning is argued to remove that reliance on the upstream repository's state.

Confirmed

  • On May 18, 2026, attackers compromised actions-cool/issues-helper along with actions-cool/maintain-one-comment in order to harvest credentials from CI/CD pipelines and send them out to a server the attacker controlled.
  • Both repositories became accessible again on September 16, 2026, between 11:09 a.m. and 6:16 p.m. GMT+2, with release tags still pointing to the May 18 malicious content.
  • Socket found both actions disabled again on September 25, 2026.
  • Per Socket, about 15,000 repositories depending on issues-helper are listed in GitHub's dependency graph; not all of them were compromised.
  • Workflows pinning either action to a pre-May 18, 2026 commit SHA are not affected.
  • The May campaign was linked to the Mini Shai-Hulud cluster via the exfiltration domain t.m-kosche[.]com, also seen in @antv npm packages.

Unknown

  • Why the repositories were re-enabled without the malicious tags being cleaned first.
  • How many of the roughly 15,000 dependents reference either action by mutable tag rather than a pinned commit.
  • Whether any downstream workflow actually exfiltrated credentials during the September 16–25 window, and at what volume.
  • Whether GitHub plans a broader audit of previously disabled repositories for the same reactivation pattern.

Our take

The interesting failure here is not the malware — that was known in May — but the containment model. Disabling a repository stops downloads; it does not remove what the tags point to. Anyone treating a takedown as remediation inherited a live payload the moment access returned. The 15,000-dependency figure is a graph statistic, not a victim count, but it shows how much CI/CD automation quietly rides on mutable references that no downstream team controls.

Sources