Disabling a repository is not removing the malware, and on 16 September the tags started working again

One hundred and twenty days offline, and nothing was cleaned

Malicious content was introduced into two GitHub Actions on 18 May 2026, as part of the Mini Shai-Hulud campaign. GitHub's security team disabled both repositories the next day, which is a fast response by any standard.

The repositories stayed unreachable for 120 days. On 16 September they became accessible again, in a window Socket narrows to between 09:09 and 16:16 UTC.

The malicious commit was still there. The release tags still pointed at it. So every workflow that referenced either action by tag rather than by a pinned commit hash resumed executing the payload on its next scheduled or triggered run, inside the runner, with that workflow's token and secrets.

What this does not establish. It does not establish how many repositories actually ran it: Socket says plainly that it has not determined how many dependents reference either action by a mutable tag rather than a pinned hash, and neither has anyone else. It does not establish why the repositories became reachable again, because GitHub has not said. It does not establish that the accounts were re-compromised, since nothing new was pushed. And it does not establish current risk from these two specific actions, because both were disabled again on 25 September, so workflows referencing them now fail at job setup instead of running anything.

What it does establish is that a disable is a reachability control and not a cleanup, and that four months of safety rested on a setting somebody could change.

Why a tag is not a version

This incident is really about one line of YAML that almost every organisation writes the wrong way.

When a workflow says it uses an action at @v2.2.1, that is not a version in the sense of an immutable artefact. It is a tag, which is a pointer to a commit, and whoever controls the repository can move it. Pinning instead to the full commit hash names the exact content, and nobody can change what that hash refers to.

GitHub has recommended pinning to a full commit hash in its own hardening guidance for years. This is the failure mode that recommendation exists for, demonstrated end to end.

The execution path in the runner is ordinary: the runner downloads the action and runs its entry point, which in this case installs a runtime and executes an obfuscated payload. There is no exploit. The workflow did what it was told, using the identity it was given, which is why the compromise reaches the secrets rather than just the source.

The timeline

Dates from Socket's research, with elapsed time computed for this briefing

Date	What happened	Elapsed
18 May 2026	Malicious content introduced into both actions	zero
19 May 2026	GitHub disables both repositories	1 day
19 May to 16 September	Repositories unreachable. Malicious commit and tags untouched	120 days
16 September 2026	Both reachable again, between 09:09 and 16:16 UTC	120 days
20 to 24 September 2026	Hijacked tags reported planting hooks in six popular repositories	124 to 128 days
25 September 2026	Both disabled again. Workflows now fail at job setup	129 days

Two things in that table deserve separating.

The response to the original compromise was good. One day from malicious commit to disabled repository is faster than most ecosystems manage, and it stopped the campaign spreading through those two actions.

The response was also incomplete in a way nobody noticed for four months. Disabling made the content unreachable without making it harmless. The moment the reachability changed, every downstream workflow that had not been fixed in the intervening 120 days went back to where it was on 18 May.

What to do about it

These two actions are disabled again, so the immediate exposure is closed. The useful work is the general case, because the next repository to come back online will not be announced either.

The question this leaves

There is a temptation to make this a story about GitHub, and it mostly is not. GitHub acted in a day, and disabling a repository is a reasonable thing to do with a compromised one. Whether the malicious content should have been purged rather than hidden is a fair question for the platform, and the answer probably involves the fact that nobody wants a platform that rewrites history in other people's repositories.

The part that belongs to everyone else is the four months. For 120 days, thousands of workflows carried a reference to a repository that had been taken down for hosting malware, and nothing in their pipelines told them to fix it, because the reference was failing quietly rather than loudly. Safety came from the upstream platform's configuration, not from anything the downstream teams had done.

So the question, and it applies to every pipeline: how many third party actions do your workflows reference by a tag that somebody else can move, and if one of them were disabled tomorrow, would your build fail loudly enough for anybody to fix the reference?