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

What it is

Two GitHub Actions, actions-cool/issues-helper and actions-cool/maintain-one-comment, were compromised in the May 2026 Mini Shai-Hulud campaign. GitHub disabled both repositories on May 19, 2026, but never cleaned up the release tags. When the repositories became reachable again on September 16, 2026, every tag-pinned workflow began downloading the old payload. Both were disabled again on September 25, so references now fail at job setup.

How it works

• At job setup the runner resolves the tag and downloads the action as a tarball. For example, actions-cool/issues-helper@v2.2.1 resolved to commit a0c53dd42fc842d2f9276c5a1d4f9a26abe8713d, whose index.js holds the obfuscated payload.
• The action installs Bun (oven-sh/setup-bun) and runs bun run $GITHUB_ACTION_PATH/index.js. The page infers the payload runs first and then hands off to the real action logic, so the workflow still appears to succeed.
• The code runs with the workflow's GITHUB_TOKEN and any secrets the workflow exposes.
• Triggers are routine: schedules, or issue and PR events. On a public repository, anyone who can open an issue can trigger an issue-event workflow. The page says most affected repositories probably ran the payload within a day.

flowchart TD
    A[Workflow uses action] --> B{Reference type}
    B -->|Tag, e.g. @v2.2.1| C{Repo state}
    B -->|Full commit SHA, pre-May 18| D[Not affected]
    C -->|Disabled| E[Fails at Set up job]
    C -->|Re-enabled Sep 16-25| F[Payload runs]

Preconditions / Affected

• The workflow references either action by tag rather than SHA.
• It ran during the exposure window, from September 16 (between 09:09 and 16:16 UTC; the exact time is unknown) until the re-disable on September 25, 2026.
• issues-helper has about 15,000 dependents in GitHub's dependency graph, and maintain-one-comment adds to that. Socket has not determined how many use mutable tags.
• The run-level evidence comes from issues-helper. The same exposure applies to maintain-one-comment because both were disabled and re-enabled together.
• A SHA pin is safe only if the pinned commit is itself clean.

What to do

1. Search .github/workflows/ in every repository you own for actions-cool/issues-helper@ and actions-cool/maintain-one-comment@. Treat any tag reference as affected. The page suggests this GitHub code search to find examples: uses: actions-cool/issues-helper@v in .github/workflows/.
2. Remove the actions, or pin them to the full SHA of a release you have verified predates May 18, 2026.
3. For any workflow that ran with a tag reference on or after September 16, 2026, rotate every secret it could access. Also review what its GITHUB_TOKEN was permitted to do.
4. Review run history for two signs: - Runs that start succeeding after a stretch of "Set up job" failures with Error: Repository access blocked. - Run durations that jump from seconds to minutes. One example went from 2 seconds to 11m25s. Another went from 5–8 seconds to 9m34s and then 4m57s.
5. 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.
6. Check repository history for commits you cannot account for, especially from September 16 onward.
7. Pin all third-party actions to full commit SHAs.

Caveats

• Socket could not determine why the repositories were re-enabled. It has not confirmed whether the maintainers requested it.
• The re-disable on September 25 stops new runs from executing the payload. It does not undo runs that already executed, so rotation and log review still apply.
• The payload's behavior is not analyzed here. The page defers to Socket's May analysis.
• The re-enablement time is only bounded to a window, not pinned down.