The malware did not return. The repository did: Mini Shai-Hulud's nine-day GitHub Actions window

The dangerous change was repository availability, not new malicious code

The GitHub Actions actions-cool/issues-helper and actions-cool/maintain-one-comment were compromised during the Mini Shai-Hulud campaign in May 2026. GitHub disabled both repositories on 19 May, a day after the malicious content was introduced. That stopped downstream runners from downloading the actions, so dependent jobs failed during setup.

Socket's investigation found that both repositories became accessible again on 16 September. Their release tags had not been cleaned first. Workflows referencing a tag such as @v2.2.1 therefore downloaded the malicious commit on their next scheduled, issue or pull-request trigger. No new publication or attacker action was required.

Socket updated its report on 25 September to say that both repositories had been disabled again. The immediate download path is closed, but the recovery question remains: which workflows ran while the repositories were reachable, and what credentials could those jobs access?

The workflow file stayed unchanged while the code behind its tag changed state

A GitHub Actions reference can name a tag or a full commit SHA. A version tag is readable and convenient, but the tag can be moved. The runner resolves it when each job starts and downloads whatever code it points to at that moment. A full commit SHA identifies one immutable Git object.

In this incident, repository disablement acted like a temporary network block. The workflow still trusted the same tag, and the tag still resolved to malicious code. Re-enabling the repository restored the missing link in the execution chain. Issue-maintenance actions are especially exposed because they often run unattended on a schedule or in response to events that outsiders can trigger.

The action code runs inside the CI job with the job's GITHUB_TOKEN and any secrets explicitly made available to the workflow. The practical impact therefore varies by repository permissions and workflow design.

Run duration supplied a useful clue

Socket compared workflow histories before and after re-enablement. A run that could not download issues-helper failed in seconds during job setup. The next observed run completed in more than eleven minutes and resolved v2.2.1 to commit a0c53dd42fc842d2f9276c5a1d4f9a26abe8713d, which Socket identified as containing the obfuscated payload. The log showed an additional Bun runtime being installed before the action executed its JavaScript.

That behaviour provides a hunt pattern even when teams did not receive a direct alert: a housekeeping workflow that changes from repeated setup failures to multi-minute successful runs, without a corresponding change in the consuming repository. It is an anomaly to investigate, not proof by itself.

Mini Shai-Hulud action timeline

Date	Event	Defensive meaning
18 May 2026	Malicious content introduced and release tags moved	Tagged consumers become exposed when runners can fetch the action
19 May 2026	GitHub disables the two repositories	Downstream jobs fail before executing the action
16 September 2026	Repositories become reachable with malicious tags intact	Tagged workflows can execute the stored payload again
25 September 2026	Socket reports both repositories disabled again	New tagged runs fail, but the nine-day execution window still requires review

Recovery starts with the workflow inventory, then follows the permissions

Containment that depends on upstream availability is reversible

Disabling a repository stopped execution, but it did not clean the compromised tags or change downstream trust. That is why the old payload could run again when availability returned. The control was effective only while a platform state remained unchanged.

The durable control is local to the consuming organisation: identify third-party automation, pin it to a verified full commit SHA, restrict job permissions and secrets, and alert when upstream dependencies change state. Pinning does not make a malicious commit safe. It prevents a clean reviewed reference from silently moving somewhere else.

Key facts