Re-Enabled GitHub Actions Expose Thousands of Repositories to Mini Shai-Hulud

Summary

Two GitHub Actions, issues-helper and maintain-one-comment, were compromised in May 2026 by the Mini Shai-Hulud campaign and subsequently disabled. On September 16, 2026, these repositories were re-enabled without cleaning the malicious tags, allowing workflows referencing them by tag to resume executing the payload. This re-enablement exposed an estimated 15,000 dependent repositories to the malware.

Full text

BackSecurity NewsRe-Enabled GitHub Actions Expose Thousands of Repositories to Mini Shai-HuludTwo compromised GitHub Actions were re-enabled with malicious tags intact, exposing thousands of downstream repositories to Mini Shai-Hulud.Karlo ZankiSep 24, 2026|7 min readTwo actions-cool GitHub Actions, issues-helper and maintain-one-comment, 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-comment 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 next 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 about 15,000 dependent repositories. Workflows that use actions-cool/maintain-one-comment 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 search 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 comment housekeeping, such as closing inactive issues, checking newly opened ones, or keeping a single bot comment 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-comment by tag.Disabled in May, Still Malicious in September#The May compromise gave the threat actor control over what both actions’ release tags resolved to. GitHub’s response was to disable the repositories instead of rewriting or removing the tags. An archived capture of the issues-helper tags page from May 19, 2026 shows the standard notice that GitHub's security team disabled access because of a terms of service violation.Wayback Machine capture of github.com/actions-cool/issues-helper/tags from May 19, 2026, showing “This repository has been disabled.”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-comment 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:GitHub Actions run “Close Inactive Issue #1849” failing in 2 seconds during Set up job with “Error: Repository access blocked”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:GitHub Actions run “Close Inactive Issue #1850” succeeding in 11m 25s, with the runner downloading actions-cool/issues-helper@v2.2.1, oven-sh/setup-bun, and a second issues-helper commitSeveral details in this log are worth noting:The runner resolves actions-cool/issues-helper@v2.2.1 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 next day’s run took 4 minutes and 57 seconds.Moonofweisheng/wot-design-uni Actions history showing “Issue Inactive” runs #790 and #791 failing in seconds on Sep 14 and 15, and run #792 on Sep 16 at 18:16 GMT+2 succeeding in 9m 34sA 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.Timeline#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-comment 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/issues-helper@v2.2.1 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 comment 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 next 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 pinne

Indicators of Compromise

• malware — Mini Shai-Hulud

Entities