📅 You're Invited: Meet the Socket team at RSAC (April 28 – May 1).RSVP
Socket
Sign inDemoInstall
Socket

Security News

GitHub Actions Supply Chain Attack Puts Thousands of Projects at Risk

A compromised GitHub Action exposed secrets in CI/CD logs, putting thousands of projects at risk and forcing developers to urgently secure their workflows.

GitHub Actions Supply Chain Attack Puts Thousands of Projects at Risk

Sarah Gooding

March 17, 2025

A widely-used GitHub Action, tj-actions/changed-files, was compromised in a supply chain attack over the weekend. It was first spotted by StepSecurity after they detected an unexpected endpoint in network traffic. On March 14–15, 2025, a threat actor gained access to the action’s repository, likely via a stolen credential, and modified version tags (v1 through v45.0.7) to point to a malicious commit. This commit injected code into workflows using the action, causing sensitive secrets from CI/CD runs to be printed into the workflow logs. The issue has been assigned CVE-2025-30066. The maintainers have since reverted the malicious changes, but not before many projects were affected.

Impact on Developers and Organizations#

The impact of this attack is significant. Over 23,000 repositories actively use tj-actions/changed-files, with around a million monthly downloads. Any workflow that pulled the malicious version would expose its secrets—including API keys, authentication tokens, and passwords—within CI/CD logs. For public repositories, this effectively made secrets accessible to anyone viewing the logs. Even for private repositories, organizations should assume their secrets were compromised since the attacker’s code had access to them.

As a result, developers and companies must now rotate potentially compromised credentials and audit their workflows to ensure they are no longer using affected versions. The incident demonstrates how even simple and trusted actions can become attack vectors, causing widespread consequences for downstream users.

Mitigation Strategies for Affected Users#

If your organization used tj-actions/changed-files, immediate action is necessary:

  • Update or remove the compromised action: Ensure your workflows are no longer referencing the affected versions. Use a secure fork or an alternative action if needed.
  • Rotate all secrets: Assume any credentials used in GitHub Actions during the breach window are compromised and revoke or regenerate them immediately.
  • Audit workflow logs: Review logs from the affected period for signs of secret exposure.
  • Delete public logs if possible: If your project is open source, consider making the repository private temporarily or removing workflow run records to limit exposure.
  • Verify your action references: Use a commit hash instead of a mutable tag to prevent similar attacks in the future.

To prevent similar supply chain attacks, developers should adopt the following best practices:

  • Pin actions to specific commit SHAs rather than mutable tags. Follow GitHub's documentation on using third-party actions.
  • Restrict third-party actions by using GitHub’s allow-listing features.
  • Monitor dependency changes in workflows, just as you would with application dependencies.
  • Apply the principle of least privilege to CI/CD workflows, limiting which secrets and permissions are exposed.
  • Use runtime security monitoring to detect suspicious activity in CI/CD jobs.
  • Regularly audit CI/CD pipelines for untrusted or outdated dependencies.

GitHub Actions as a Growing Attack Vector#

This incident highlights a concerning trend: attackers are increasingly targeting GitHub Actions and CI/CD workflows as an entry point for supply chain attacks. By compromising a popular GitHub Action, an attacker can instantly affect thousands of downstream projects. Similar incidents in the past have included compromised workflows leaking publishing tokens, allowing attackers to push malicious software updates, as recently seen in the Ultralytics supply chain attack.

As more organizations rely on GitHub Actions for automation, securing CI/CD infrastructure is as critical as securing application code. When including a third-party GitHub Action, developers are effectively executing someone else’s code in their environment. Organizations must treat their build systems as production environments—locking down dependencies, monitoring for anomalies, and enforcing stricter access controls to continue leveraging automation safely.

Subscribe to our newsletter

Get notified when we publish new security blog posts!

Try it now

Ready to block malicious and vulnerable dependencies?

Install GitHub AppBook a demo

Related posts

Back to all posts