On March 11, 2025, The reviewdog/action-setup GitHub Action became the focus of a significant supply chain attack. Malicious activity was first detected when researchers observed that the v1 tag of reviewdog/action-setup had been altered between 18:42 and 20:31 UTC, allowing attackers to inject malicious code into the tool. This modification went unnoticed for a short period, but the consequences were immediate and widespread.
Background
GitHub Actions Overview
Before we delve deeper into the attack, it’s essential to understand how GitHub Actions work. GitHub Actions allow developers to automate tasks such as code building, testing, and deployment using pre-configured workflows. Developers often rely on third-party GitHub Actions, like reviewdog, which helps with automated code review by integrating it into continuous integration/continuous deployment (CI/CD) pipelines.
What Happened?
It all began with a seemingly harmless GitHub Action, reviewdog/action-setup, designed to streamline code reviews. Unfortunately, on March 17, this action was compromised by attackers, allowing them to slip malicious code into the heart of workflows that relied on it.
Within just a few hours:
- Developers worldwide saw their CI/CD workflows execute this tampered action, unknowingly giving attackers access to sensitive environment variables.
- This led to widespread secrets leaks, affecting everything from private API keys to Personal Access Tokens (PATs).
The alarming aspect? Most of the victims had no idea their secrets were being exposed until it was too late.
Attack Methodology
This wasn’t just a simple attack; it a was well-coordinated attack designed to exploit the trust developers place in third-party GitHub Actions. Here’s how the attackers managed to wreak havoc:
- Malicious Code Injection
The attackers modified the reviewdog/action-setup Action by injecting a Base64-encoded malicious payload into the install.sh script. This script runs during setup and executes commands for the installation of Reviewdog, allowing it to access sensitive environment variables.
Once executed in the CI/CD pipeline, the malicious code would:
- Decode the Base64-encoded payload to reveal a script designed to extract secrets.
- Read environment variables, such as API keys, access tokens, and other confidential data.
- Print or encode this sensitive information in workflow logs, making it publicly accessible.
- Execution in Workflow
The compromise was stealthy since many workflows used the reviewdog/action-setup@v1 tag, allowing the injected malicious code to execute across many repositories without detection. The attack went unnoticed until security researchers identified the unauthorized changes in the action’s setup script.
- Compromised Personal Access Token (PAT)
As part of the attack, the tj-actions-bot account’s Personal Access Token (PAT) was compromised, giving attackers the ability to modify downstream actions. This led to the unauthorized modification of repositories using tj-actions/changed-files, further exacerbating the exposure of sensitive credentials.
- Supply Chain Propagation
The compromise extended to tj-actions/eslint-changed-files and other actions that relied on reviewdog/action-setup. In particular, tj-actions/changed-files, a popular action that detects changed files in pull requests, was compromised as it inherited the malicious setup from reviewdog/action-setup.
Mistakes Made?
- Usage of Mutable Version Tags
One of the primary vulnerabilities exploited in this attack was the use of mutable version tags (v1), which allowed the attacker to silently introduce malicious code without altering the version number. This practice is common in GitHub workflows but poses a significant risk, as it can allow undetected changes to run in production environments.
- Weak Token Security
The compromised Personal Access Token (PAT) used by tj-actions-bot highlights the importance of stricter token management. Weak token security allowed the attackers to escalate their privileges and modify repositories, leading to further propagation of the attack.
Impact
The cascading supply chain attack led to the exposure of CI/CD secrets from over 23,000 repositories in the case of tj-actions/changed-files. Although the reviewdog compromise itself affects a smaller subset (limited to the v1 tag), its role in the chain has significant implications.
Recommendations
Audit and Identify
- Use GitHub search queries or automation tools to identify workflows that reference the affected reviewdog/action-setup@v1 and dependent actions.
- Review CI/CD logs for evidence of the malicious payload (look for double-encoded Base64 strings).
Rotate Compromised Credentials
- Immediately rotate any secrets that might have been exposed, including PATs, AWS keys, and other sensitive tokens.
Remove or Replace Affected Actions
- Stop using the affected actions across all branches not just the main branch, to prevent inadvertent execution.
- Replace references to mutable version tags with pinned commit hashes. This prevents future modifications from going undetected.
Adopt Immutable Versioning
- Always use specific commit SHAs instead of mutable tags (v1, latest). This practice ensures that the exact version of an action is being used and prevents attackers from altering code in previously trusted versions.
Audit Third-Party Actions
- Regular audits of third-party actions should be conducted to ensure that no unauthorized changes have been made. GitHub’s security features, such as Dependabot and CodeQL, should be employed to scan for vulnerabilities.
Conclusion
The reviewdog/action-setup supply chain attack highlights the critical security risks associated with CI/CD pipelines and third-party dependencies. The cascading nature of the attack, where a single compromised action led to a widespread breach, underscores the need for stricter security practices in the GitHub Actions. By taking immediate steps to audit affected workflows, rotate credentials, and improve token security, organizations can mitigate the damage caused by this attack and prevent future incidents.
