actions-cool/issues-helper GitHub Action compromised through tag poisoning: all tags point to credential-stealing imposter commit

The actions-cool/issues-helper GitHub Action — used by thousands of repositories for automated GitHub issue management — was compromised on May 18, 2026 through tag poisoning. First reported by StepSecurity, an attacker with write access to the repository force-moved every existing Git tag to reference a single malicious "imposter commit" that does not appear in the repository's normal branch history. Any workflow referencing the action by tag — @v1, @v2, @v3, and all others — pulled the malicious payload on its next run.

This attack follows the identical pattern as the tj-actions/changed-files compromise (CVE-2025-30066), which had significant industry impact. The mechanism is reproducible against any GitHub Action repository where an attacker can obtain write access: no vulnerability in GitHub Actions itself is required.

Tag poisoning mechanism

The imposter commit exists in the repository's Git object store — it is a valid Git object — but is unreachable from any branch head. This makes it invisible through normal repository browsing on GitHub: the Commits tab, the file browser, and pull request history will not surface it. The commit can only be fetched by its raw SHA.

By force-moving all existing tags to point to this commit, the attacker ensured that every tag-based reference in every consumer workflow would resolve to the malicious payload on the next run. The attack requires no changes to consumer workflows — the poisoning happens entirely at the source repository.

Payload: Bun download + Runner.Worker memory scraping

When a workflow executes the compromised action, the payload performs three steps:

1. Runtime download: Downloads the bun JavaScript runtime onto the GitHub Actions runner, providing an execution environment outside the standard Node.js Action runtime.
2. Process memory harvesting: Reads memory from the Runner.Worker process, which holds the workflow's decrypted secrets at runtime. This technique bypasses standard secret masking — secrets that appear as *** in workflow logs are present in plaintext in Runner.Worker memory and can be captured by any process with sufficient privileges on the same runner. Cloud credentials, registry tokens, OIDC tokens, and any other secrets configured for the workflow are exposed.
3. Credential exfiltration: Outbound HTTPS call to an attacker-controlled domain with the harvested material.

The Runner.Worker memory scraping technique is particularly significant: it indicates the attacker understands the GitHub Actions runner architecture at a deep level and is targeting the one place where all workflow secrets coexist in plaintext. Standard detection focused on env variable access or file-based secret paths will miss this collection vector.

Scope: all tag references affected

Because every tag was re-pointed, all tag-based references resolve to the malicious commit. The scope is not limited to a specific version — @v1, @v2, @v3, and any other tag-based reference all point to the same imposter commit. Only workflows pinned to a full 40-character commit SHA of a known-good commit are unaffected.

Detection

• Search your organization's workflows for actions-cool/issues-helper. Any reference by tag after May 18, 2026 should be treated as having executed the malicious payload.
• Review workflow run logs for unexpected outbound network connections from runs that executed the action by tag.
• Check for OIDC token usage from unexpected sources during the compromise window — the payload can harvest OIDC tokens that enable cloud identity impersonation.

Remediation

1. Remove all references to actions-cool/issues-helper from workflows immediately. Comment out or delete the action until the maintainer confirms a verified clean commit.
2. Rotate all secrets available to any workflow that executed this action by tag reference after May 18, 2026. This includes cloud provider credentials, container registry tokens, npm/PyPI publish tokens, and any other secrets in the affected repositories.
3. Audit workflow run logs for outbound network connections to unexpected domains.
4. Pin all remaining third-party GitHub Actions to full commit SHAs. This is the only reliable defense against tag-poisoning attacks. Tags are mutable references. SHA pins are not.
5. Review OIDC-based keyless authentication workflows (e.g., aws-actions/configure-aws-credentials) for unauthorized cloud activity during the compromise window.

Class context: tag poisoning is a repeatable GitHub Actions attack pattern

The tj-actions/changed-files compromise (CVE-2025-30066) established this attack pattern at scale and it is now confirmed repeatable. Tag poisoning requires only write access to the target repository — which can be obtained through stolen tokens, compromised maintainer accounts, or malicious pull request merges. The GitHub Actions ecosystem's convention of pinning by tag rather than SHA is the structural weakness that makes every mutable Action tag a potential delivery vector. Organizations that have not already pinned all third-party Actions to SHA references should treat this as an urgent remediation item independent of any specific campaign.