GitHub Actions as an attack vector

Blog  — Tue 25 Mar 2025

Suppose you're a cracker not looking to find backdoors, but to create them. Then what? One option is to infiltrate GitHub and carry out a supply chain attack that impacts thousands of CI/CD pipelines.

March 2025 was marked by a large-scale supply chain attack that exposed the vulnerabilities of CI/CD environments. A malicious modification in a popular GitHub Action led to the leakage of sensitive data at thousands of organizations worldwide.

The attack: from reviewdog to thousands of repositories

The attack began with the compromise of the GitHub Action reviewdog/action-setup@v1. It was modified to log secret tokens in the workflow logs. This malicious version was then included in tj-actions/eslint-changed-files, an action used by more than 23,000 projects. As a result, the CI/CD environments of over 4,000 organizations were exposed to data leaks.

Impact on major players

Among the affected organizations was Coinbase, with the agentkit repository specifically mentioned. Although no direct damage was reported, the incident highlights the risks of relying on third-party actions within CI/CD pipelines.

Versioning vulnerabilities

A key factor in the spread of the attack was the use of mutable version tags such as @v1. These tags point to changeable versions, allowing malicious updates to be introduced without notice. This underscores the importance of using specific commit hashes or immutable version tags to maintain the integrity of CI/CD pipelines.

What can organizations do?

  • Use specific versions: Avoid using mutable tags like @latest or @v1. Instead, refer to specific commit hashes.
  • Limit access to secrets: Ensure secrets are only accessible to the workflow steps that actually need them.
  • Implement monitoring: Keep a close eye on logs and workflows for unusual activity.
  • Perform regular audits: Routinely check the integrity and origin of actions and dependencies in use.

If you rely on the work of others, you must keep reviewing that work to prevent ‘borrowed’ code from opening backdoors in your own software.

In short, relying on third-party components requires heightened awareness and proactive measures to safeguard the integrity of software delivery processes.