Two Compromised GitHub Actions Came Back With Their Malicious Tags

On 24 September 2026, Socket reported that two GitHub Actions compromised in May's Mini Shai-Hulud campaign, actions-cool/issues-helper and actions-cool/maintain-one-comment, had become accessible again on 16 September. GitHub had disabled both repositories on 19 May, one day after the malicious code went in, but had not rewritten the release tags. When the repositories came back, workflows that referenced them by tag started running the payload again. Socket's 25 September update says both were disabled once more.

What's affected

• Actions: actions-cool/issues-helper and actions-cool/maintain-one-comment.
• Bad code: introduced on 18 May 2026. Socket gives one example: the v2.2.1 tag of issues-helper resolved to commit a0c53dd42fc842d2f9276c5a1d4f9a26abe8713d.
• Exposure window: from 16 September, between 09:09 and 16:16 UTC by Socket's estimate, until the repositories were disabled again around 25 September.
• Who: any workflow that referenced either action by tag rather than by a commit SHA from before 18 May. GitHub's dependency graph lists about 15,000 dependent repositories for issues-helper alone. Socket did not determine how many of those use tags.

When we loaded the issues-helper repository on 18 October, GitHub showed "This repository has been disabled" with a terms of service notice.

The mechanism, per Socket: at job setup, the runner downloads whatever the tag currently points to. The malicious wrapper installs Bun with oven-sh/setup-bun and runs an obfuscated index.js before the action's real logic, so the job can still finish green. That code has the workflow's GITHUB_TOKEN and every secret the workflow exposes. These actions usually run on schedules or on issue and pull request events, and on a public repository anyone who can open an issue can trigger some of them.

How to check if you're exposed

Find references in every repository you own, including forks and archived repos you still run workflows from:

grep -rnE 'actions-cool/(issues-helper|maintain-one-comment)@' .github/workflows/

A reference ending in a 40-character commit SHA from before 18 May is pinned. Anything ending in @v1, @v2, @v2.2.1 or a branch name is a mutable reference and was exposed while the repositories were live.

Then review Actions run history between 16 and 25 September for these workflows. Socket's tells:

• Jobs that had been failing at "Set up job" since May and suddenly succeeded.
• Runtimes that jumped from seconds to minutes.
• Log lines showing oven-sh/setup-bun being downloaded and bun run executing index.js from the action path.

What to do now

1. Remove both actions or pin them to a verified commit SHA from before 18 May 2026. Given the history, removing them is simpler.

2. Rotate secrets available to any workflow that ran a tag reference on or after 16 September, including cloud keys, registry tokens and deploy keys.

3. Audit repository history from 16 September onward for commits, releases, tags or workflow changes you don't recognise. The GITHUB_TOKEN may have had write access.

4. Set the default GITHUB_TOKEN to read-only at the organization level, and grant write per job only where needed.

5. Pin every third-party action to a full commit SHA, and let a dependency bot propose SHA updates so pins don't go stale. A comment with the tag name next to the SHA keeps them readable:

   - uses: some-org/some-action@0123456789abcdef0123456789abcdef01234567 # v2.2.0
   

Why it matters

Disabling a repository is a pause, not a fix. As long as the tags point to malicious commits, every workflow that references them is one switch away from running the payload again. Here the switch was flipped four months later, and Socket couldn't establish why.

Tags in GitHub Actions are mutable pointers. A workflow that says @v2 trusts whoever controls that tag today and on every future run, including after an incident has been "handled". Pinning to a SHA turns that open-ended trust into a reviewed, fixed version. The same applies to container images referenced by tag and to package ranges that float to the latest release.

The failing-then-passing signal is worth automating. A workflow that has been broken since a known incident and suddenly goes green is exactly the kind of change that deserves an alert.

Try it yourself

List every uses: line in one repository and sort them into three groups: pinned to a SHA, pinned to a tag, and pinned to a branch.

grep -rhoE 'uses: *[^ #]+' .github/workflows/ | sed 's/uses: *//' | sort -u |
  awk -F@ '{ if ($2 ~ /^[0-9a-f]{40}$/) print "SHA    " $0; else if ($2 ~ /^v?[0-9]/) print "TAG    " $0; else print "BRANCH " $0 }'

Everything outside the SHA group runs whatever its owner points it at next time.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Socket: Re-enabled GitHub Actions expose thousands of repositories to Mini Shai-Hulud
• GitHub: actions-cool/issues-helper repository page