On May 19, 2026, StepSecurity disclosed an active supply chain attack against actions-cool/issues-helper, a widely used GitHub Action for automating issue and pull-request triage in CI workflows. An attacker with write access to the repository moved every one of its 53 release tags to point at a single imposter commit — a commit that is not reachable from the action’s default-branch history and never went through a pull request. A second action from the same organization, actions-cool/maintain-one-comment, was hit with the identical technique, with 15 of its tags repointed to the same payload. GitHub has since disabled both repositories for a “violation of GitHub’s terms of service.”

The imposter commit technique

An imposter commit is a commit that exists in a repository’s object store but is not reachable from any legitimate branch. Git tags are just mutable pointers to commit objects; nothing forces a tag to reference a commit that is part of the project’s real history. When an attacker can write to a repo, they can fast-forward — or simply re-point — a tag to an arbitrary commit, including one pushed from an adversary-controlled fork. Because the malicious code never appears in a pull request, it bypasses code review entirely. Consumers see a familiar version tag and assume the audited history behind it; in reality the tag now resolves to attacker code.

The payload

When a workflow invokes the compromised action, the imposter commit’s code runs inside the GitHub Actions runner and:

  • Downloads the Bun JavaScript runtime onto the runner.
  • Reads memory from the Runner.Worker process — the process that holds the workflow’s decrypted secrets in cleartext.
  • Makes an outbound HTTPS request to the attacker domain t.m-kosche[.]com to exfiltrate the harvested credentials.

Scraping Runner.Worker memory is the dangerous part. GitHub masks secrets in build logs, but inside the runner those values live unmasked in process memory while the job executes — GITHUB_TOKEN, OIDC identity tokens, registry publish tokens, cloud keys, and signing material. A process-memory read sidesteps every log-masking and secrets context protection GitHub provides. The exfiltration domain t.m-kosche[.]com is the same domain observed in the current Mini Shai-Hulud wave against npm’s @antv ecosystem, so the two campaigns are very likely the same actor cluster.

Impact

Any workflow that references either action by a tag — actions-cool/issues-helper@v3, @v1, or any pinned version string — pulls the malicious code on its next run, because all tags now resolve to the imposter commit. Only workflows pinned to a known-good full 40-character commit SHA are unaffected. issues-helper is commonly used in issues- and pull_request-triggered automation, jobs that frequently carry a write-scoped GITHUB_TOKEN. Every secret exposed to a job running the action — repo tokens, publish credentials, cloud keys — should be treated as compromised.

What to do right now

  • Grep your workflows for actions-cool/issues-helper and actions-cool/maintain-one-comment. If either is referenced by tag, assume secrets reachable by those jobs are exposed.
  • Rotate immediately: any PAT, npm/PyPI/container-registry token, cloud key, or signing key a job using these actions could read. GITHUB_TOKEN is short-lived, but rotate everything else.
  • Review Actions run history since May 18-19 for jobs that invoked the actions, and check egress logs for connections to t.m-kosche[.]com.
  • Pin every third-party action to a full commit SHA, not a tag. Tags are mutable; SHAs are not. This attack does not work against SHA-pinned references.
  • Enforce hash-pinning with Dependabot or Renovate, and consider an allowlist of permitted actions at the org level.
  • StepSecurity’s Action-Uses-Imposter-Commit detection flags any action referenced via a SHA or moved tag that does not match a legitimate tag or branch head — the exact signature of this attack.

References