GitHub Actions Supply Chain Attack Steals CI/CD Secrets

In yet another escalation of software supply chain attacks, threat actors have compromised one of the most widely used GitHub Actions workflows — actions-cool/issues-helper — turning its entire release tag history into a delivery mechanism for credential-stealing malware. The attack, disclosed by StepSecurity on May 19, 2026, represents a sophisticated evolution in CI/CD pipeline exploitation that every DevOps team should understand.

How the Attack Worked: The Imposter Commit Technique

The core of this attack revolves around what StepSecurity researcher Varun Sharma calls an imposter commit. Instead of injecting malicious code through a pull request — which would trigger code review — the attackers manipulated Git tags so that every existing version tag in the repository now points to a commit that exists only in an adversary-controlled fork, not the original trusted repository.

“Every existing tag in the repository has been moved to point to an imposter commit that does not appear in the action’s normal commit history,” Sharma explained in the disclosure. “That commit contains malicious code that exfiltrates credentials from CI/CD pipelines that run the action.”

This is particularly dangerous because most GitHub Actions workflows reference actions by version tag (e.g., actions-cool/[email protected]) rather than by full commit SHA. When a tag is silently reassigned, every downstream workflow automatically pulls the malicious version on its next execution — no code change, no pull request, no alert.

The Three-Stage Payload

Once a compromised runner executes the imposter commit, the malicious payload unfolds in three distinct stages:

First, it downloads the Bun JavaScript runtime onto the GitHub Actions runner. Bun, a fast JavaScript runtime often used in CI/CD environments, serves as the execution environment for the next stages. Using a legitimate runtime helps the malware blend in with normal pipeline activity.

Second, it reads memory from the Runner.Worker process — the core GitHub Actions process that manages job execution. This process holds sensitive credentials in memory, including GITHUB_TOKEN, repository secrets, and any other secrets injected into the workflow. By scanning the Runner.Worker’s memory space, the malware extracts these credentials without triggering file system monitoring or secret-scanning tools.

Third, it exfiltrates the stolen data via an HTTPS call to t.m-kosche[.]com, an attacker-controlled domain. HTTPS traffic to external domains is common in CI/CD pipelines (for fetching dependencies, calling APIs), making this exfiltration difficult to distinguish from legitimate traffic.

Scope of the Compromise

The attack doesn’t stop at issues-helper. StepSecurity confirmed that 15 tags associated with a second GitHub Action from the same organization — actions-cool/maintain-one-comment — were also compromised with identical malicious functionality. Both actions are part of the popular actions-cool ecosystem, which provides utilities for automated issue management, labeling, and commenting in GitHub repositories.

The actions-cool/issues-helper action alone has been used by thousands of repositories. Any workflow that references the action by tag version — which is the default and documented approach — is potentially affected. Only workflows that pin dependencies to a known-good full commit SHA are immune, a practice that remains uncommon despite years of security guidance recommending it.

GitHub has since disabled access to the compromised repository, citing a “violation of GitHub’s terms of service.” However, the window of exposure — the time between tag compromise and repository takedown — remains unknown.

Connection to the Mini Shai-Hulud Campaign

Perhaps the most concerning aspect of this incident is its apparent connection to a broader supply chain attack campaign. The exfiltration domain t.m-kosche[.]com has also been observed in the latest wave of the Mini Shai-Hulud campaign, which recently compromised npm packages from the @antv ecosystem — a popular data visualization library used by thousands of JavaScript projects.

Philipp Burckhardt, head of threat intelligence at Socket, confirmed the overlap: “That points to the same Mini Shai-Hulud activity cluster, not a separate npm-only incident. We’re still being careful about the exact initial access path, but the overlap is strong enough that we’re treating them as related.”

This cross-ecosystem attack pattern — targeting both npm packages and GitHub Actions — suggests a coordinated campaign aimed at infiltrating the software supply chain at multiple entry points. Developers who use both @antv packages and actions-cool workflows could face compounded exposure.

Why This Matters for Your Pipeline

This attack exposes a fundamental weakness in how most teams manage CI/CD dependencies. Despite years of warnings from security researchers, the vast majority of GitHub Actions workflows reference actions by semantic version tags — @v1, @v2.1, or @main — rather than by immutable commit SHAs. Tags are mutable pointers; commit SHAs are cryptographic guarantees.

The fix is straightforward but operationally tedious: pin every GitHub Action to a full commit SHA. This means replacing references like actions/checkout@v4 with actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29. While this eliminates automatic patch updates, it also eliminates the attack vector demonstrated here.

Additional mitigations include enabling GitHub’s allowed actions policy to restrict workflows to a curated list of verified actions, using OpenID Connect (OIDC) instead of long-lived secrets for cloud provider authentication, and implementing workflow run monitoring to detect anomalous outbound connections from CI/CD runners.

The Bigger Picture

This incident is not an isolated event. The software supply chain has become the primary attack surface for sophisticated threat actors. Earlier this year, reports surfaced about a CISA contractor who leaked AWS GovCloud credentials on GitHub, demonstrating that even security-conscious organizations struggle with CI/CD hygiene. The 18-year-old NGINX rewrite module vulnerability that went undetected for nearly two decades shows how deeply vulnerabilities can embed themselves in widely trusted infrastructure.

What makes the actions-cool attack different is the tag redirection technique. Traditional supply chain attacks compromise a package at its source — injecting malicious code into a new version. This attack compromised the pointer to the code, leaving the original source untouched while redirecting consumers to a malicious fork. It’s a more subtle, harder-to-detect approach that exploits the trust placed in version tags.

What's Next

As of this writing, GitHub has disabled the compromised repositories, but the investigation is ongoing. The Mini Shai-Hulud connection suggests the full scope of this campaign remains unknown. Security teams should audit their GitHub Actions workflow files immediately, checking for any reference to actions-cool/* actions and verifying whether they’re pinned to commit SHAs rather than tags.

For the broader community, this incident should serve as a catalyst for adopting immutable dependency references across the entire software supply chain — not just in package managers like npm and PyPI, but in CI/CD workflow definitions, Docker base images, and infrastructure-as-code templates.