Two GitHub Actions Disabled Since May's Mini Shai-Hulud Compromise Came Back Online in September, Reactivating Malware With No New Attack
Socket found that actions-cool/issues-helper and actions-cool/maintain-one-comment, disabled since May 2026, became reachable again on September 16 with their malicious tags intact, silently re-running the payload.
Overview
Two GitHub Actions that were disabled in May 2026 after being compromised in the Mini Shai-Hulud supply-chain campaign became reachable again on September 16, 2026, and their malicious release tags — never cleaned up while the repositories were disabled — resumed executing on every downstream workflow that referenced them by version tag, according to Socket. No new exploit, account compromise, or code change was involved: the only change was that the repositories could be downloaded again. The Hacker News reports that GitHub has since disabled both repositories for a second time.
What We Know
The original May compromise
The actions actions-cool/issues-helper and actions-cool/maintain-one-comment were “compromised and disabled during the May 2026 Mini Shai-Hulud campaign,” Socket writes. As previously reported, that campaign compromised more than 170 npm and PyPI packages starting May 11, 2026. In this specific case, Socket says GitHub’s “security team disabled both repositories on May 19, 2026, one day after the malicious content was introduced” on May 18. The Hacker News adds that the two actions were originally compromised to run code that harvested credentials from CI/CD pipelines and exfiltrated them to an attacker-controlled server.
Repositories became reachable again on September 16
According to Socket, “on September 16, 2026, both repositories became accessible again. 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 Hacker News independently confirms the same date and quotes Socket researcher Karlo Zanki making the identical point. Socket narrows the re-enablement to a window: “both repositories were re-enabled on September 16, 2026, between 11:09 and 18:16 GMT+2 (09:09–16:16 UTC). The exact time is not known.” The Hacker News separately reports the window as “between 11:09 a.m. and 6:16 p.m. GMT+2,” the same span in different notation. Socket says it “could not determine why they were re-enabled,” adding that “a request from the legitimate maintainers is one possibility, but we have not confirmed it.”
How the payload ran again without any new attack
Socket traced the mechanism to a specific commit: the runner “resolves actions-cool/[email protected] to commit a0c53dd42fc842d2f9276c5a1d4f9a26abe8713d which contains the malicious obfuscated payload inside index.js.” The workflow step then “installs Bun and then runs bun run $GITHUB_ACTION_PATH/index.js, effectively executing the payload inside the CI runner.” Socket illustrates the effect with one workflow run: “the next run of the same workflow, #1850, took 11 minutes and 25 seconds. This time the runner downloaded the action, and the log shows what the v2.2.1 tag now resolves to” — compared with prior runs that failed within seconds while the repository was still disabled. A second example comes from a public repository’s own scheduled job: in the Moonofweisheng/wot-design-uni project’s “Issue Inactive” workflow, Socket found that “on September 14 and 15, the scheduled runs failed in 8 and 5 seconds. On September 16 at 18:16 (GMT+2), run #792 succeeded and took 9 minutes and 34 seconds. The next day’s run took 4 minutes and 57 seconds.”
Socket sums up why this required no new attacker action: “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.” Both actions, Socket notes, “automate issue and comment housekeeping, such as closing inactive issues, checking newly opened ones, or keeping a single bot comment up to date,” and typically “run on a daily schedule or whenever someone opens an issue or pull request” — meaning “most affected repositories probably ran the payload within a day of the re-enablement, with no further action needed from the threat actor.”
Scale of exposure
Socket puts a number on the potential blast radius: “for actions-cool/issues-helper alone, GitHub’s dependency graph lists about 15,000 dependent repositories.” The company was explicit about the limits of that figure, however, noting it “has not determined how many dependents reference either action by mutable tag instead of a pinned commit SHA” — meaning the 15,000 figure is the outer bound of exposure, not a confirmed victim count. Workflows pinned to a clean commit SHA predating May 18 were never affected, according to Socket.
A second disabling
As of publication, GitHub’s own page for the repository shows the standard suspension notice: “This repository has been disabled. Access to this repository has been disabled by GitHub Staff due to a violation of GitHub’s terms of service.” The Hacker News reports that both actions-cool repositories “have been disabled for a second time after the repositories became accessible last week,” indicating GitHub moved to re-contain the exposure following Socket’s disclosure.
What We Don’t Know
Socket says it could not determine why the two repositories were made reachable again on September 16, and neither Socket nor The Hacker News names a party responsible for the reactivation. Socket also has not quantified how many of the roughly 15,000 dependent repositories actually reference the actions by mutable tag rather than a pinned SHA, so the true number of workflows that executed the payload during the exposure window is unknown. Neither source specifies how long the repositories remained reachable before GitHub disabled them again.
Analysis
Socket frames the incident as a containment failure rather than a new compromise: disabling a repository stops downstream workflows from fetching it, but it does not alter the malicious content sitting inside its tags. “Disabling a repository is a strong containment measure,” Socket writes, “but it is temporary, and it does nothing to the malicious content. If the repository is re-enabled, the containment is gone, and every downstream consumer that relied on it is exposed again without any notice.” The company’s core recommendation is unchanged from its original May guidance: pin third-party GitHub Actions to a full commit SHA rather than a mutable version tag, since “a mutable tag can be compromised, contained, and then reactivated without any change to your own workflow file,” while “SHA pinning removes that dependency on the upstream repository’s state.”