Mutable Tags Strike Again: actions-cool GitHub Action Tags Redirected to Imposter Commits (May 2026)

In mid-May 2026, StepSecurity researcher Varun Sharma flagged something subtle in two popular GitHub Actions. Every tag on actions-cool/issues-helper, and 15 tags on actions-cool/maintain-one-comment, had been quietly moved. Not deleted, not rewritten in history that anyone would notice on a casual glance, but repointed. As Sharma put it, every existing tag had been moved to point to an imposter commit that does not appear in the action's normal commit history. Any workflow that referenced these actions by tag, which is the overwhelmingly common way people reference them, would pull and execute the imposter commit on its next run.

The imposter commit was a credential stealer. It downloaded the Bun JavaScript runtime, used it to extract credentials from the Runner.Worker process memory, and shipped the loot over HTTPS to an attacker-controlled domain, t.m-kosche[.]com. That domain overlapped with infrastructure seen in the contemporaneous Mini Shai-Hulud campaign hitting the npm @antv ecosystem, suggesting linked threat clusters rather than a one-off.

This is not a novel technique. It is the same mutable-tag weakness that made the 2025 tj-actions incident so damaging, applied to a new pair of actions in May 2026. That it keeps working is the story. This post covers the verified facts, the mechanics of the tag-redirect attack class, why SHA pinning is the durable fix, and what to check Monday morning.

TL;DR

• In May 2026, StepSecurity reported that all tags on actions-cool/issues-helper and 15 tags on actions-cool/maintain-one-comment were moved to point at imposter commits absent from the actions' normal history.
• The imposter commit downloaded the Bun runtime, extracted credentials from the Runner.Worker process memory, and exfiltrated them via HTTPS to t.m-kosche[.]com.
• Any workflow referencing these actions by mutable tag (for example @v3) pulled the malicious code on its next run. Workflows pinned to a commit SHA were unaffected.
• The exfiltration domain overlaps with the Mini Shai-Hulud campaign targeting npm @antv packages, indicating connected threat activity.
• Microsoft/GitHub disabled access to the actions-cool/maintain-one-comment repository for a terms-of-service violation.
• No CVE is required to understand the fix: pin third-party actions to immutable commit SHAs, restrict runner egress, and inventory tag-pinned references across your fleet.

What happened

StepSecurity's Varun Sharma identified that the tags on actions-cool/issues-helper (all existing tags) and actions-cool/maintain-one-comment (15 tags) had been repointed to commits that do not appear in the actions' legitimate commit histories. The mechanism is git's mutable-tag behavior: a lightweight or annotated tag is just a movable pointer to a commit. Whoever controls the repository (through a compromised maintainer account or a malicious insider) can move a tag to any commit, including one created solely to carry malware. Consumers who reference the action as actions-cool/issues-helper@v3 resolve that tag at run time and get whatever it currently points to.

The imposter commit's payload, per StepSecurity, downloaded the Bun JavaScript runtime, then used it to read credentials out of the memory of the Runner.Worker process, the GitHub Actions component that holds the secrets and tokens exposed to a job. It transmitted the stolen data over HTTPS to t.m-kosche[.]com. StepSecurity noted that this exfiltration domain overlaps with the Mini Shai-Hulud campaign that was simultaneously targeting npm packages in the @antv ecosystem, which is why the two clusters are believed to be linked.

GitHub's parent Microsoft responded by disabling access to the actions-cool/maintain-one-comment repository, citing a violation of GitHub's terms of service. At the time of writing there is no formal CVE; like the mass-injection and pipeline-hijack incidents of the same month, this is an abuse-of-trust event rather than a software vulnerability.

How the attack worked

The mutable-tag primitive

A GitHub Actions reference like uses: actions-cool/issues-helper@v3 does not pin to specific code. It pins to a name. At workflow run time, GitHub resolves v3 to whatever commit the v3 tag currently points to in that repository. Tags are mutable by anyone with push access. So the security of every @v3-style reference depends entirely on the upstream maintainer's account never being compromised and never acting maliciously, indefinitely, for as long as you keep using the action.

When an attacker gains push access, moving the tag is trivial. An illustrative, non-functional sketch of the operation:

# Illustrative. This is what tag redirection looks like, not a working exploit.
git tag -f v3 <imposter-commit-sha>
git push --force origin refs/tags/v3
# every consumer of @v3 now resolves to the imposter commit on next run

Crucially, the imposter commit need not appear in the linear history a casual viewer sees. Pointing a tag at a dangling or out-of-history commit, as reported here, makes the change easy to miss unless you are specifically comparing the tag's target SHA against a known-good value.

Stealing secrets from Runner.Worker memory

Once the imposter action executes inside a job, it runs with the permissions and secret access of that job. The reported payload pulled down the Bun runtime (a fast JavaScript runtime, useful here because it is a single self-contained binary that runs the stealer logic without relying on whatever is preinstalled on the runner) and used it to read credentials from the Runner.Worker process memory.

Reading runner process memory is the same class of technique used in the tj-actions and Megalodon incidents: rather than relying only on environment variables, the payload scrapes the process that holds the secrets, capturing tokens that may not be neatly exposed as env vars. The harvested credentials were then POSTed over HTTPS to t.m-kosche[.]com. HTTPS exfiltration to a plausible-looking domain blends into normal CI egress unless the network is locked down to an allowlist.

Why SHA-pinned workflows were safe

A workflow that referenced the action by immutable commit SHA, for example uses: actions-cool/issues-helper@a1b2c3d..., resolved to the exact bytes of the original, legitimate commit regardless of where the v3 tag was moved. The tag redirect simply does not affect a SHA reference, because there is no name to re-resolve. This is the same lesson tj-actions taught in 2025, and it remained the dividing line in May 2026 between affected and unaffected consumers.

What detection looks like

• A change in the commit SHA that a third-party action tag resolves to, when you did not intend to upgrade. If you pin to tags, you have no record of this; if you record the resolved SHA, a diff is your detection.
• Workflow runs that download a language runtime (Bun, Deno, or similar) inside a third-party action step that has no documented reason to do so. A comment-helper action fetching a JavaScript runtime is anomalous.
• Reads against the Runner.Worker process or unusual process inspection from within a CI job.
• Outbound HTTPS from CI runners to unfamiliar domains such as t.m-kosche[.]com, or any destination outside your egress allowlist during a build.
• For these specific actions: any current use of actions-cool/issues-helper or actions-cool/maintain-one-comment referenced by tag.

A quick inventory of tag-pinned third-party action references across a repo or org is the highest-value detection step. An illustrative search across a checked-out repository:

# Illustrative. Find third-party action references that are NOT pinned to a 40-char SHA.
grep -rEn "uses:\s+[^@]+@(v[0-9]|[a-z])" .github/workflows/ \
  | grep -vE "@[0-9a-f]{40}"

Lines this returns are tag- or branch-pinned references, each of which is exposed to a tag-redirect attack.

What to do Monday morning

Ordered by urgency.

1. Search your fleet for actions-cool/issues-helper and actions-cool/maintain-one-comment. If you find either referenced by tag, treat any secret reachable from those workflows as exposed during the window the malicious tag was live. Rotate those credentials.
2. Rotate credentials exposed to affected runs first. GITHUB_TOKEN scope, cloud keys, registry tokens, and anything the affected jobs could read. Do this before you simply bump the reference.
3. Pin every third-party action to a full commit SHA. Replace @v3-style references with the 40-character SHA of a reviewed, known-good commit. Tools like pinact and ratchet automate the conversion and can verify it in CI.
4. Add a CI check that blocks new tag- or branch-pinned third-party action references. Make SHA pinning a merge requirement so the fleet does not drift back to mutable tags over time.
5. Restrict runner egress to an allowlist. HTTPS exfiltration to t.m-kosche[.]com only works if the runner can reach it. Allowlisted egress neutralizes this exfiltration path even when a malicious action runs.
6. Set GITHUB_TOKEN permissions to least privilege per workflow. Declaring explicit minimal permissions: shrinks what a hijacked action can do with the token it scrapes.
7. Inventory and review your third-party action footprint regularly. Every action is standing arbitrary-code-execution trust in an external maintainer. Treat the list as a managed dependency, not set-and-forget.

Why this keeps happening

The mutable-tag weakness is not a bug; it is a usability decision baked into how Actions are referenced. Tags like v3 are pleasant to read, they let maintainers ship patch fixes without consumers changing anything, and they are what every action's README example uses. The cost of that convenience is that every tag reference is a live, indefinite trust relationship with whoever controls the upstream repository, re-evaluated on every single workflow run. The day that maintainer's account is compromised, or the day a malicious actor gains push access, every downstream consumer pinned to a tag inherits the attacker's code automatically.

GitHub has recommended SHA pinning since 2022 and shipped immutable-action capabilities since, yet tag references remain the default in documentation and in the wild. So the same attack that worked against reviewdog and tj-actions in 2025 worked against actions-cool in May 2026, and will work against the next popular action whose maintainer account is phished. The technique is durable because the incentive structure that produces unpinned references is durable. Until SHA pinning is the path of least resistance rather than a hardening chore, the mutable-tag attack class will keep producing incidents.

The structural fix

What shortens dwell time against tag-redirect attacks is knowing, continuously, which of your workflow references are mutable and which upstream actions just changed underneath you. Safeguard inventories every GitHub Actions reference across your repository fleet, flags any reference pinned to a mutable tag rather than a commit SHA, and offers conversion to a reviewed SHA with a policy gate that blocks new tag-pinned references from merging. Griffin AI tracks the behavioral baseline of the actions your workflows invoke and alerts when an action's resolved code changes in ways consistent with a tag-redirect or history-rewrite, the pattern shared by tj-actions, Megalodon, and actions-cool. Reachability analysis tells you which repositories actually expose privileged secrets to third-party actions, so when an incident like this lands you triage by real exposure rather than by raw action count. None of this stops a maintainer account from being compromised upstream, but it collapses the gap between "the tag moved" and "we noticed."

What we know we don't know

There is no CVE and, at the time of writing, no public confirmation of how the attacker obtained push access to the actions-cool repositories (maintainer-account compromise versus insider action is not stated). The number of downstream workflows that executed the imposter commit before the repositories were disabled is not public. The overlap with the Mini Shai-Hulud @antv activity is reported as infrastructure overlap, which is suggestive of a shared operator but stops short of firm attribution. And the precise set of credential types successfully exfiltrated from any given victim depends on what each affected job had access to, which is not enumerable from the public record.

References

• The Hacker News: Popular GitHub Action Tags Redirected to Imposter Commit to Steal CI/CD Credentials
• StepSecurity blog (research source for the actions-cool tag-redirect finding)
• GitHub Advisory Database: tj-actions/changed-files (CVE-2025-30066), the prior mutable-tag incident
• Unit 42: GitHub Actions Supply Chain Attack (tj-actions background on mutable-tag abuse)

Internal reading:

• SLSA provenance
• Policy enforcement
• Reachability analysis
• Software composition analysis
• Secret detection use case
• Maintainer takeover detection