GitHub Actions Supply Chain Attack

The recent GitHub Actions supply chain attack represents a multi-layered, targeted compromise that initially focused on Coinbase before escalating into a widespread incident affecting thousands of repositories. This sophisticated attack exploited critical CI/CD misconfigurations and leveraged leaked Personal Access Tokens (PATs) to gain unauthorized access, potentially leading to data breaches and code tampering. The primary objective was to exploit public CI/CD flows to facilitate further compromises, specifically targeting sensitive workflow secrets. This incident underscores the critical need for robust CI/CD security, proactive monitoring, and maintaining supply chain integrity to prevent similar future occurrences.

II. Incident Overview: A Multi-Layered Supply Chain Compromise

Nature of the Attack

This incident was a software supply chain compromise where attackers skillfully abused third-party actions and dependencies. The goal was to gain unauthorized access, potentially leading to data breaches and code tampering. A key objective was to exploit public CI/CD flows to leverage for further compromises, specifically targeting sensitive workflow secrets.   

Methodology – Initial Access & Lateral Movement

The attack began in November 2024 with the compromise of SpotBugs, an open-source Java static analysis tool. A malicious GitHub Actions workflow was pushed to spotbugs/spotbugs, executing a workflow run that leaked all spotbugs/spotbugs secrets, including a PAT belonging to a reviewdog maintainer (RD_MNTNR). This PAT provided access to both spotbugs/spotbugs and reviewdog/action-setup. The leaked secrets and their encryption key were encrypted with a hard-coded RSA public key, ensuring only the attacker could decrypt them. The malicious branch (hewrkbwkyk) was created and deleted within one second to minimize traces.  

Following this, on March 11, 2025, the attacker created a disposable user named jurkaofavak, which was invited as a member to the spotbugs/spotbugs repository by a compromised SpotBugs maintainer (SPTBGS_MNTNR). This invitation, occurring just two minutes before the malicious branch push, indicates SPTBGS_MNTNR’s PAT was also compromised. The significant time lag, over three months, between the initial leak of SPTBGS_MNTNR’s PAT on December 6, 2024, and its active exploitation on March 11, 2025, suggests a highly sophisticated and patient adversary. Attackers likely conducted extensive reconnaissance and planning during this period, mapping permissions and identifying further targets, such as the    

reviewdog dependency chain, before launching the main attack. This highlights that a seemingly dormant compromised credential can still pose a significant long-term threat, necessitating immediate revocation of any leaked credentials and continuous monitoring for unusual or delayed activity.

Methodology – Supply Chain Propagation

Using the leaked RD_MNTNR’s PAT, the attacker overrode the v1 tag in the reviewdog/action-setup repository, redirecting it to a malicious commit (b833eecd) originating from a fork. This was achieved by pushing new git tags, a critical maneuver that is notably not recorded in GitHub’s audit log for free-tier organizations, allowing the attacker to evade detection. This demonstrates a calculated exploitation of a platform limitation, as the absence of audit logs for such a critical action significantly hampers detection and response. The attacker also used a dummy user,   

iLrmKCu86tjwp8, to create forks and introduce malicious commits, subsequently deleting the fork to make the commits untraceable.   

The tj-actions/changed-files action was compromised indirectly, as it depended on tj-actions/eslint-changed-files, which in turn relied on the already compromised reviewdog/action-setup. When tj-actions/eslint-changed-files executed, the tj-actions/changed-files CI runner’s secrets were leaked, including a PAT belonging to the tj-bot-actions GitHub user account. The attacker then pushed a malicious commit to tj-actions/changed-files, disguised as a legitimate renovate[bot] pull request, overriding existing git tags to point to this malicious commit. This impacted every GitHub workflow run that depended on tj-actions/changed-files. This cascading compromise illustrates how a vulnerability deep within a dependency tree can propagate upwards, affecting widely used actions and amplifying risk across thousands of downstream projects.   

Finally, a specific campaign targeted Coinbase. Dummy users forked Coinbase repositories like coinbase/agentkit. A malicious commit was found in tj-actions/changed-files specifically targeting coinbase/agentkit, which was then pulled and executed by coinbase/agentkit‘s CI workflow, leading to credential leakage.   

III. Detailed Timeline of Events

The following table provides a chronological overview of key events during the GitHub Actions supply chain attack:

IV. Key Vulnerabilities Exploited & Impact Assessment

Vulnerabilities Exploited

The attack leveraged several critical weaknesses:

• Leaked Personal Access Tokens (PATs): The entire attack chain was predicated on the leakage of PATs with sufficient permissions.  
• pull_request_target trigger: This GitHub Actions trigger was exploited for initial PAT leakage, leading to a Poisoned Pipeline Execution (PPE) attack.  
• Git Tag Manipulation: Attackers exploited the fact that git tag changes are not recorded in GitHub’s audit log for free-tier organizations, enabling stealthy introduction of malicious commits.   
• Commit Impersonation: Malicious commits were disguised by impersonating legitimate users, such as renovate[bot], within valid pull requests.   
• Auto-invite Mechanism: The reviewdog organization’s auto-invite mechanism, which automatically grants contributors write permissions, may have served as an entry point.   
• Excessive GitHub Actions Pipeline Permissions: Workflows configured with write-all permissions amplified the impact of leaked GITHUB_TOKENs.   
• Unpinned GitHub Actions: Referencing GitHub actions by mutable tags or branches (e.g., @v3 or @main) instead of a full-length commit SHA-1 hash allowed attackers to alter the underlying code without changing the version reference.   

The attack’s success relied on a combination of compromised human credentials, exploitation of automated CI/CD features, and social engineering. This demonstrates that even with robust technical controls, the human factor remains a critical weak link. Automation, while essential for efficiency, can become a significant amplifier for attacks if not rigorously secured and monitored. The ease of impersonation also highlights a fundamental trust vulnerability in automated commit attribution within CI/CD pipelines. Therefore, security strategies must be holistic, encompassing robust Identity and Access Management (IAM) practices, mandatory multi-factor authentication (MFA), continuous security awareness training for developers, and rigorous security reviews of all automated processes and their associated permissions.

Impact

The consequences of this compromise were significant:

• Compromise of CI/CD Pipelines: Thousands of repositories had their continuous integration/continuous delivery (CI/CD) pipelines compromised.   
• Sensitive Data Exposure: The attackers injected a payload designed to dump the CI/CD runner’s memory, exposing sensitive environment variables and secrets directly to workflow logs.   
• Unauthorized Access and Data Breaches: The incident underscores the potential for unauthorized access, data breaches, and code tampering.   
• Widespread Risk: The tj-actions/changed-files GitHub action was used by over 23,000 GitHub repositories, placing a significant number of them at risk.   
• Targeted Attacks: While Coinbase stated the attack was unsuccessful in causing damage to their project or assets, sensitive information was collected during the initial spear-targeting campaign.   

V. Proactive Defense & Detection Recommendations

Immediate Steps for Affected Users

Organizations should take immediate action if potentially affected:

• Identify Usage: Search for tj-actions/changed-files and other mentioned actions within repositories.   
• Review Workflow Logs: Examine past workflow runs for any evidence of secret exposure, typically appearing as double-encoded Base64 text, especially in public logs.  
• Rotate Secrets: Immediately revoke and regenerate any exposed credentials, including API keys, access tokens, and deployment credentials.   
• Investigate Malicious Activity: If signs of execution of the compromised action are found, conduct a thorough investigation for any further malicious activity.   

Long-Term Security Improvements

Proactive measures are essential for preventing similar incidents:

• Govern Third-Party Services: Implement strict vetting procedures for external actions before integrating them into workflows.  
• Implement Strict Pipeline-Based Access Controls (PBAC): Reduce permissions granted to GitHub Actions workflows to the absolute minimum necessary, prioritizing fine-grained and short-lived tokens over long-term, broadly scoped secrets.  
• Pin GitHub Actions: Always pin actions to a full-length commit SHA-1 hash instead of mutable tags or branches (e.g., @v3 or @main) to prevent malicious code changes without altering the version reference. 
• Restrict GitHub Actions Usage: If feasible, configure policies to allow only Enterprise actions or a curated list of trusted actions to prevent the execution of external, potentially untrusted actions. 
• Avoid Excessive Pipeline Permissions: Do not define read-all or write-all permissions in pipelines, as this grants overly broad access if the GITHUB_TOKEN is leaked. 
• Use OpenID Connect (OIDC): Replace long-term credentials with short-lived access tokens for cloud provider authentication, as OIDC tokens expire automatically and allow more granular control.

The fact that this sophisticated attack occurred by leveraging well-known vulnerabilities indicates a widespread gap between understanding best practices and consistently implementing them. Many organizations, particularly smaller open-source projects, may lack the resources or expertise to fully enforce these controls, and manual adherence across numerous repositories is often impractical. This highlights the need for automated policy enforcement, continuous monitoring, and vulnerability scanning throughout the CI/CD pipeline, with platform providers offering more secure-by-default options.

Checking Other IT Systems for Similar Attack Paths

To identify and protect against similar risks across other IT systems, organizations should:

• Leverage Security Tools: Utilize platforms designed to identify executables and GitHub actions in pipelines, enabling the discovery of vulnerable actions and the implementation of out-of-the-box policies. Such tools can provide enhanced capabilities to allow or restrict the usage of tools in pipelines and track the deployment of forbidden tools.   
• Implement Out-of-the-Box CI/CD Policies: Actively apply predefined policies to detect and mitigate risks from unpinned GitHub actions, unrestricted usage of GitHub actions (e.g., based on author or source), excessive GitHub Actions pipeline permissions, and GitHub actions accessing cloud providers using insecure long-term credentials (promoting OIDC for short-lived tokens).   
• Unified Application Security: Employ comprehensive tools that unify findings from code, pipeline, runtime, application context, and third-party sources within a single risk, policy, and automation engine for a holistic security posture.   
• Contact Incident Response: For urgent matters or suspected compromises, specialized Incident Response teams should be contacted without hesitation.