Mini Shai Hulud Actions

Two compromised GitHub Actions were re-enabled with malicious tags intact, exposing thousands of downstream repositories to Mini Shai-Hulud.

Update, September 25, 2026 : both actions-cool/issues-helper and actions-cool/maintain-one- have been disabled on GitHub again, so workflows referencing them now fail at job setup instead of running the payload.

Two actions-cool GitHub Actions, issues-helper and maintain-one- , were compromised and disabled during the May 2026 Mini Shai-Hulud campaign. Both became reachable again on September 16, 2026, and their release tags still point to malicious code, so every workflow that references either one by tag rather than by commit SHA is running the payload again.

The GitHub Actions actions-cool/issues-helper and actions-cool/maintain-one- were compromised in the May 2026 Mini Shai-Hulud campaign . GitHub security team disabled both repositories on May 19, 2026, one day after the malicious content was introduced. Disabling the repositories stopped the attack: downstream workflows could no longer download either action, so they failed before any action code ran.

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 run.

The threat actor did not need a new exploit, new infrastructure, or a new compromise for this to happen. The malicious code had been sitting in place since May, and the only change was that the two repositories could be downloaded again. Socket could not determine why they were re-enabled. A request from the legitimate maintainers is one possibility, but we have not confirmed it. Compromised GitHub Actions were reported to GitHub support.

The exposure is large. For actions-cool/issues-helper alone, GitHub’s dependency graph lists 15,000 dependent repositories. Workflows that use actions-cool/maintain-one- add to that. Socket has not determined how many dependents reference either action by mutable tag instead of a pinned commit SHA. A GitHub code for uses: actions-cool/issues-helper@v in .github/workflows/ returns many such workflows.

These workflows also tend to run often. Both actions automate issue and housekeeping, such as closing inactive issues, checking newly opened ones, or keeping a single bot up to date. The workflows that call them usually run on a daily schedule or whenever someone opens an issue or pull request. In practice, most affected repositories probably ran the payload within a day of the re-enablement, with no further action needed from the threat actor.

The run-level evidence in this post comes from workflows that use actions-cool/issues-helper . Both repositories were disabled and re-enabled at the same times, so the same exposure applies to workflows that reference actions-cool/maintain-one- by tag.

Disabled in May, Still Malicious in September #

While a repository is disabled, the GitHub Actions runner cannot fetch it. Workflows that depend on it fail during the Set up job step, while the runner is still resolving and downloading actions and before any workflow step runs. That failure protected downstream projects, but only as long as the repositories stayed disabled. The malicious tags stayed in both repositories the whole time.

At the time of writing, the release tags of both actions-cool/issues-helper and actions-cool/maintain-one- still resolve to the malicious content introduced on May 18.

What Changed on September 16 #

Workflow run histories from affected repositories show when the actions became downloadable again. Before the re-enablement, runs that referenced actions-cool/issues-helper failed within a few seconds. The runner log for a “Close Inactive Issue” run shows the job stopping at Getting action download info with Error: Repository access blocked :

The 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:

Several details in this log are worth noting:

The runner resolves actions-cool/[email protected] to commit a0c53dd42fc842d2f9276c5a1d4f9a26abe8713d which contains the malicious obfuscated payload inside index.js .

The workflow step installs Bun and then runs bun run $GITHUB_ACTION_PATH/index.js , effectively executing the payload inside the CI runner.

An issue-housekeeping action has no obvious reason to install a separate JavaScript runtime and run a multi-minute script before doing its actual work. This structure fits a wrapper that runs malicious code first and then hands off to action logic, so the workflow still appears to succeed. Socket’s May analysis covers the payload itself.

The same pattern shows up in the run history of the Moonofweisheng/wot-design-uni “Issue Inactive” workflow ( issue-inactive.yml ), which runs on a daily schedule. 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 day’s run took 4 minutes and 57 seconds.

A scheduled workflow switching from failing in seconds to running for several minutes without any change to its own code means the action it depends on became downloadable again.

All times are as observed in the GitHub Actions UI and are shown in GMT+2, with UTC in parentheses.

Based on these observations, 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.

Why Tag References Were Hit Again #

The problem comes from how GitHub Actions resolves dependencies:

The tags were compromised and never cleaned up. The release tags of both actions-cool/issues-helper and actions-cool/maintain-one- point to malicious content. When the repositories were re-enabled on September 16, the tags came back as they were.

Downstream workflows reference a mutable tag. A reference such as uses: actions-cool/[email protected] names a Git tag, not a fixed commit. Tags can be moved, so whatever the tag points to when the job starts is what gets run.

The runner fetches and runs the action on each job. At job setup, the runner downloads every referenced action as a tarball and runs it inside the job. The action code has access to the workflow’s GITHUB_TOKEN and to any secrets the workflow exposes.

Triggers are routine and often externally reachable. Issue and workflows run on a schedule or on issue and pull request events. Any GitHub user who can open an issue on a public repository can trigger an issue-event workflow.

No further threat actor action is required. Once the repositories were reachable, the scheduled or event-triggered run on each affected repository ran the payload.

Workflows that pin either action to the full commit SHA of a version from before May 18 are not affected by the tag compromise. SHA pinning protects a workflow only if the pinned commit is itself clean.

Discussion: Re-Enablement as a Security Regression #

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. Two repositories that had been disabled for security reasons were made public again while they still contained the same malicious tags. That one change was enough to reactivate a months-old compromise across a dependency graph that, for issues-helper alone, includes 15,000 repositories.

It also shows how dependent open source projects are on one another. For most of the affected projects, issues-helper and maintain-one- are small tools for closing stale issues or keeping a bot up to date. They do not ship in anyone’s product, and many maintainers probably forgot they were there. They still run with the workflow’s token and secrets, on a schedule, with no human reviewing each run. A small, trusted piece of automation that nobody watches gives an attacker a lot of reach.

Disabling a repository is a strong containment measure. 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. Platform security teams should treat re-enabling a repository that was disabled for a compromise as a high-impact decision. Before access is restored, they should confirm that tags, releases, and default branches no longer point to malicious content. They should also consider how many downstream workflows will resolve those references the moment the repository comes back online.

Consumers cannot control when a platform re-enables a repository. They can control how their workflows reference third-party actions. A workflow pinned to a known-clean commit SHA would not have been affected by either the May compromise or the September re-enablement.

Find every reference to the affected actions. .github/workflows/ in all repositories you own for actions-cool/issues-helper@ and actions-cool/maintain-one- @ . Treat any tag-based reference, such as @v2.2.1 , as affected.

Remove the actions or pin them to a known-clean SHA. Replace tag references with the full commit SHA of a release you have verified to predate May 18, 2026, or remove the actions entirely.

Rotate exposed secrets. For any workflow that ran with a tag reference to either action on or after September 16, 2026, rotate every secret that workflow could access, and review what the job’s GITHUB_TOKEN was allowed to do.

Review workflow run history. Look for runs that start succeeding after a stretch of Set up job failures, and for runs whose duration jumps from seconds to minutes. In runner logs, look for oven-sh/setup-bun being downloaded or bun run $GITHUB_ACTION_PATH/index.js being executed as part of either action.

Audit repository history for unexpected commits. Check affected repositories for commits you cannot account for, especially from September 16, 2026 onward.

Pin all third-party actions to full commit SHAs. This incident shows that a mutable tag can be compromised, contained, and then reactivated without any change to your own workflow file. SHA pinning removes that dependency on the upstream repository’s state.

Indicators of Compromise #

Compromised GitHub Actions #

As of the time of writing, all release tags of both actions resolve to malicious content:

actions-cool/issues-helper

actions-cool/maintain-one-

For more technical details and the full list of Mini Shai-Hulud payload indicators, see Socket’s May 2026 research post .