GitHub Actions Supply Chain Attack Redirects Repository Tags to Credential-Stealing Malware

Threat actors have executed a sophisticated supply chain attack against two widely-used GitHub Actions repositories, redirecting every existing tag to malicious commits that steal credentials from CI/CD pipelines. The compromised repositories—actions-cool/issues-helper and actions-cool/maintain-one-comment—now serve malware to any workflow that references them by version tag rather than pinned commit SHA.

StepSecurity researcher Varun Sharma identified the attack vector: attackers moved all repository tags to point at imposter commits containing credential-harvesting code. These malicious commits exist outside the normal commit history, allowing adversaries to inject code without triggering standard pull request review processes. GitHub has disabled access to the repositories for violating terms of service, though the initial compromise vector remains under investigation.

Imposter Commit Technique Bypasses Standard Security Controls

The attack exploits a fundamental weakness in how development teams reference GitHub Actions dependencies. An imposter commit is a deceptive technique where malicious code references commits or tags that exist only in attacker-controlled forks rather than the trusted upstream repository. By redirecting legitimate tags to these imposter commits, attackers achieve arbitrary code execution within CI/CD pipelines without ever submitting code through the repository's normal review process.

This technique is particularly dangerous because it affects repositories retroactively. Organizations that implemented these Actions months or years ago—and passed security reviews at that time—now execute malicious code on their next workflow run. Only teams that pinned dependencies to full commit SHAs rather than version tags remain protected.

Three-Stage Credential Exfiltration Process

Once executed within a GitHub Actions runner, the malicious code performs a coordinated attack sequence designed to extract and transmit sensitive credentials:

• Downloads the Bun JavaScript runtime to the compromised runner environment
• Reads process memory from Runner.Worker to extract authentication credentials and secrets
• Establishes HTTPS connection to attacker-controlled domain t.m-kosche[.]com to exfiltrate stolen data

The choice of Bun runtime is strategic—it provides attackers with a modern JavaScript execution environment that may evade detection systems looking for traditional Node.js patterns. The memory-reading capability is particularly concerning, as it can extract credentials that never touch disk or appear in log files.

Connection to Mini Shai-Hulud Campaign

The exfiltration domain t.m-kosche[.]com links this GitHub Actions attack to the ongoing Mini Shai-Hulud campaign targeting npm packages. Security researchers previously observed this same infrastructure in attacks against packages from the @antv ecosystem. Philipp Burckhardt, head of threat intelligence at Socket, confirmed the connection: 'That points to the same Mini Shai-Hulud activity cluster, not a separate npm-only incident. The overlap is strong enough that we're treating them as related.'

This infrastructure overlap indicates a coordinated campaign targeting multiple package ecosystems simultaneously. The threat actor demonstrates sophisticated understanding of both npm and GitHub Actions supply chains, suggesting an organized group rather than opportunistic attackers. The campaign name references the sandworms from Dune—fitting for an attack that burrows through software supply chains.

Why Version Tags Create Security Risk

This attack exposes a critical security assumption in modern DevOps practices. Most teams reference GitHub Actions using semantic version tags like v1 or v1.2.3 because they balance convenience with perceived stability. Version tags are mutable—repository maintainers can move them to different commits, enabling security patches without requiring downstream updates.

But mutability is also vulnerability. When attackers gain control of a repository, they inherit the ability to redirect tags. In this case, every workflow that trusted the v1 tag now executes attacker code. Commit SHAs, by contrast, are immutable cryptographic hashes. Pinning to a full 40-character SHA prevents this attack vector entirely, though it sacrifices automatic security updates.

Broader Implications for CI/CD Security

This incident demonstrates that CI/CD pipelines represent high-value targets with privileged access to credentials, source code, and deployment infrastructure. GitHub Actions runners operate with permissions that often exceed those of individual developers—they can read secrets, push to production branches, and deploy to cloud environments. A compromised Action inherits all these capabilities.

The attack's sophistication—using imposter commits to bypass review, extracting credentials from process memory, and coordinating across multiple package ecosystems—suggests adversaries are investing significant resources in supply chain attack techniques. Organizations must treat CI/CD security with the same rigor they apply to production infrastructure. That means dependency pinning, network egress monitoring, least-privilege secrets management, and continuous auditing of pipeline configurations.

Recommended Actions

Security teams should immediately audit all GitHub Actions workflows for references to compromised repositories. Search workflow files for 'actions-cool/issues-helper' and 'actions-cool/maintain-one-comment' regardless of version. Check Actions logs from the past 30 days for outbound connections to t.m-kosche[.]com or unusual network activity during workflow execution.

Rotate all credentials accessible to affected workflows, including GitHub tokens, cloud provider credentials, API keys, and deployment secrets. Assume any secret available to a compromised workflow has been exfiltrated. Update dependency references to use full commit SHAs from the last known-good state before compromise. For the actions-cool repositories, that means identifying the legitimate commit history before tags were redirected.

Long-term, implement policies requiring all external Actions to be pinned by SHA rather than tag or branch. Enable GitHub's dependency review features and security advisories. Consider using tools like StepSecurity's Harden-Runner to add runtime monitoring and egress filtering to GitHub Actions workflows. Treat CI/CD supply chain security as a first-class concern, not an afterthought.