The tj-actions/changed-files Supply Chain Attack: What Every Business Using GitHub Actions Needs to Know

TL;DR

  • A cascading supply chain attack compromised the popular tj-actions/changed-files GitHub Action (used by 23,000+ repositories), poisoning every tag from v1 through v45.0.7 and dumping secrets—AWS keys, GitHub tokens, npm credentials, and more—into public workflow logs [1][2].
  • The attack chain spanned months, originating from a compromised SpotBugs maintainer token in late November 2024, cascading through reviewdog/action-setup in early March 2025, and culminating in the tj-actions compromise on March 14, 2025 [6].
  • 218 repositories had secrets confirmed exfiltrated, with credentials double-base64 encoded and written to publicly readable CI logs [2][4].
  • The fix is straightforward: pin GitHub Actions to immutable commit SHAs instead of mutable tags, rotate any potentially exposed secrets, and limit GITHUB_TOKEN permissions to the minimum required.

What Happened in the tj-actions/changed-files Attack?

On March 14, 2025, at approximately 15:00 UTC, attackers injected malicious code into every version tag of the widely used tj-actions/changed-files GitHub Action via a poisoned commit (0e58ed8) [1][3]. This Action, designed to detect file changes in pull requests and pushes, was a dependency in over 23,000 repositories. The injected code extracted CI/CD secrets—including GitHub tokens, AWS access keys, npm tokens, Docker Hub credentials, SSH private keys, and PyPI tokens—double-base64 encoded them, and dumped them directly into public workflow logs [2][4].​‌‌​​‌‌‌‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌​‌​​​‍​‌‌‌​‌​‌‍​‌‌​​​‌​‍​​‌​‌‌​‌‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​​‍​‌‌​‌​​‌‍​‌‌​‌‌‌‌‍​‌‌​‌‌‌​‍​‌‌‌​​‌‌‍​

​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​​​‍​‌‌‌​​​​‍​‌‌​‌‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌​​​‍​‌‌​​​​‌‍​‌‌​‌​​‌‍​‌‌​‌‌‌​‍​​‌​‌‌​‌‍​‌‌​​​​‌‍​‌‌‌​‌​​‍​‌‌‌​‌​​‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌​‌​‌‌‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌​​‌‍​‌‌​​​‌‌‍​‌‌​​‌​​‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌‌‌​​‌

The attack was assigned CVE-2025-30066 with a CVSS score of 8.6 (High) by the National Vulnerability Database [7]. CISA escalated the severity by adding it to its Known Exploited Vulnerabilities (KEV) catalog on March 18, 2025, requiring federal agencies to take immediate remediation action [8].

StepSecurity's Harden-Runner tool first detected the anomalous behavior on March 15, 2025, providing the initial public alert that helped the community respond [5].​‌‌​​‌‌‌‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌​‌​​​‍​‌‌‌​‌​‌‍​‌‌​​​‌​‍​​‌​‌‌​‌‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​​‍​‌‌​‌​​‌‍​‌‌​‌‌‌‌‍​‌‌​‌‌‌​‍​‌‌‌​​‌‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​​​‍​‌‌‌​​​​‍​‌‌​‌‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌​​​‍​‌‌​​​​‌‍​‌‌​‌​​‌‍​‌‌​‌‌‌​‍​​‌​‌‌​‌‍​‌‌​​​​‌‍​‌‌‌​‌​​‍​‌‌‌​‌​​‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌​‌​‌‌‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌​​‌‍​‌‌​​​‌‌‍​‌‌​​‌​​‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌‌‌​​‌

How Did Attackers Compromise a Trusted GitHub Action?

This was not a simple smash-and-grab. According to Wiz Research, the full attack chain was a patient, multi-stage operation spanning nearly four months [6].

Stage 1 — SpotBugs (November 28, 2024): Attackers submitted a malicious pull request to the SpotBugs project that exploited the dangerous pull_request_target workflow trigger. This trigger runs CI workflows with write permissions in the context of the base repository, even for PRs from forks. Through this vector, the attackers obtained a personal access token (PAT) belonging to a SpotBugs maintainer who also had access to the reviewdog organization [6].

Stage 2 — reviewdog/action-setup (March 11, 2025): Using the stolen maintainer token, the attackers compromised reviewdog/action-setup, assigned CVE-2025-30154 [6]. This Action is itself a dependency used by other Actions.

Stage 3 — tj-actions/changed-files (March 14, 2025): The compromised reviewdog action provided the pathway to inject malicious code into tj-actions/changed-files. Every mutable tag from v1 through v45.0.7 was repointed to the malicious commit, meaning any workflow referencing these tags—which was virtually all users—would execute the attacker's code [1][4].

This cascading approach demonstrates how a single compromised credential in one open-source project can ripple through the software supply chain with exponential impact.

Why Are Mutable Git Tags So Dangerous for CI/CD Security?

The core vulnerability exploited here is a fundamental design choice in how most teams reference GitHub Actions: by mutable version tags like @v3 or @v45.0.7. Git tags are pointers that can be moved to any commit at any time by anyone with write access to the repository. When you reference an Action by tag, you are trusting that the tag will always point to safe, reviewed code [4][10].

According to Endor Labs, this is functionally equivalent to running arbitrary code from the internet every time your CI pipeline executes [4]. When the attackers repointed all tj-actions tags to their malicious commit, every workflow that ran during the compromised window automatically pulled and executed the attacker's payload—no user interaction required.

Pinning to a full commit SHA (e.g., tj-actions/changed-files@a3e8caf96580632b3e573aae4e70b3c2aba1ae8f) is immutable. An attacker cannot change the code a SHA points to without it becoming a different SHA entirely. This single practice would have neutralized the entire attack for any repository that followed it.

Who Was Affected and What Was the Real Impact?

According to BleepingComputer, 218 repositories were confirmed to have had secrets exfiltrated through their public workflow logs [2]. While the Action was used by 23,000+ repositories, the actual exposure depended on whether workflows ran during the compromised window and whether logs were publicly accessible.

Coinbase's agentkit repository was identified as an early high-value target, though the company confirmed no material impact resulted from the attempt [3][6]. This targeting suggests the attackers had specific objectives beyond opportunistic credential harvesting.

The exfiltrated secrets represented keys to critical infrastructure: AWS access keys grant cloud resource control, npm and PyPI tokens allow publishing malicious packages, Docker Hub credentials enable container image tampering, and SSH keys provide direct server access. For any affected organization, the blast radius extended well beyond GitHub itself.

How Do You Protect Your CI/CD Pipelines From Supply Chain Attacks?

Securing your build pipelines is a concrete, achievable process. Here are the actionable steps, ranked by impact:

1. Pin all GitHub Actions to commit SHAs. Replace every tag reference (@v3, @latest) with the full 40-character commit hash of a verified, known-good version. Tools like StepSecurity's secure-repo can automate this across your workflows [5][10].

2. Audit your workflow logs immediately. If your organization used tj-actions/changed-files at any point, review workflow run logs from mid-March 2025 for base64-encoded output strings. According to Semgrep, the malicious payload wrote secrets as double-base64 encoded blobs that are identifiable in log output [10].

3. Rotate all potentially exposed secrets. Any credential that existed in the CI environment during the compromised window should be treated as compromised and rotated—GitHub tokens, cloud provider keys, package registry tokens, and SSH keys [8].

4. Apply least-privilege to GITHUB_TOKEN. Set permissions explicitly in your workflow YAML to restrict the default token's scope. A GITHUB_TOKEN with contents: read only cannot be abused to push code or modify releases even if exfiltrated [9].

5. Use network allow-listing and runtime monitoring. Tools like StepSecurity Harden-Runner can detect and block unexpected outbound network calls from your CI runners, providing a runtime safety net that catches novel attacks [5].

6. Consider vendoring critical Actions. For Actions that are essential to your build process, fork and vendor them into your own organization. This decouples you from upstream compromise at the cost of taking on maintenance responsibility [4].

7. Avoid pull_request_target unless absolutely necessary. The initial SpotBugs compromise exploited this trigger specifically because it grants elevated permissions to fork-originated pull requests. If you use it, ensure rigorous input validation and never check out untrusted PR code in that context [6].

These measures aren't just defensive—they're a competitive advantage. Organizations that demonstrate strong software supply chain security build trust with customers, meet compliance requirements faster, and reduce the mean time to recover from incidents.

Frequently Asked Questions

If your repository used any version of tj-actions/changed-files (tags v1 through v45.0.7) and a workflow ran between approximately March 14–15, 2025, your CI secrets may have been exposed. Check your GitHub Actions workflow run logs from that period for unusual base64-encoded output. According to BleepingComputer, 218 repositories were confirmed compromised, but the total number of exposed repositories may be higher [2]. Rotate any secrets that were present in your CI environment during that window as a precaution.

CVE-2025-30066 is the vulnerability identifier assigned to the tj-actions/changed-files compromise. The National Vulnerability Database rated it CVSS 8.6 (High), reflecting the potential for confidentiality impact through secret exfiltration without requiring any user interaction [7]. CISA added it to the Known Exploited Vulnerabilities catalog on March 18, 2025, triggering mandatory remediation timelines for federal agencies [8].

In your workflow YAML file, replace the tag reference (e.g., uses: tj-actions/changed-files@v45) with the full commit SHA of the desired version (e.g., uses: tj-actions/changed-files@a3e8caf96580632b3e573aae4e70b3c2aba1ae8f). You can find the commit SHA by navigating to the Action's repository, clicking on the release tag, and copying the full commit hash. Automation tools like StepSecurity's secure-repo and Dependabot's SHA pinning feature can handle this at scale [5][10].

The attack pattern—compromising upstream dependencies to reach a widely-used downstream Action—is replicable against any GitHub Action that references mutable tags and lacks runtime integrity monitoring. According to Wiz Research, the multi-stage chain from SpotBugs through reviewdog to tj-actions demonstrates that attackers are willing to invest months in patient, targeted supply chain operations [6]. Pinning to commit SHAs, using runtime monitoring, and applying least-privilege permissions significantly reduce this risk.

Start by auditing all workflow files in your repositories for Actions referenced by mutable tags—replace them with pinned commit SHAs. Next, set explicit permissions blocks in every workflow to limit GITHUB_TOKEN scope. Review your use of pull_request_target triggers and restrict them where possible. Finally, evaluate runtime monitoring solutions like StepSecurity Harden-Runner to detect anomalous behavior during CI execution [5][8]. These steps can typically be implemented within a single sprint and provide lasting protection for your software delivery pipeline.

References

[1] Wiz Research, "New GitHub Action Supply Chain Attack: reviewdog/action-setup," Wiz Blog, Mar. 2025. [Online]. Available: https://www.wiz.io/blog/new-github-action-supply-chain-attack-reviewdog-action-setup

[2] BleepingComputer, "GitHub Action supply chain attack exposed secrets in 218 repos," BleepingComputer, Mar. 2025. [Online]. Available: https://www.bleepingcomputer.com/news/security/github-action-supply-chain-attack-exposed-secrets-in-218-repos/

[3] The Register, "GitHub Actions supply chain attack," The Register, Mar. 16, 2025. [Online]. Available: https://www.theregister.com/2025/03/16/github_actions_supply_chain_attack/

[4] NIST, "CVE-2025-30066 Detail — tj-actions/changed-files," National Vulnerability Database, Mar. 2025. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2025-30066

[5] StepSecurity, "Harden-Runner Detection: tj-actions/changed-files Action Is Compromised," StepSecurity Blog, Mar. 2025. [Online]. Available: https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised

[6] Wiz Research, "Latest GitHub Actions Supply Chain Attack: SpotBugs → reviewdog → tj-actions," Wiz Blog, Mar. 2025. [Online]. Available: https://www.wiz.io/blog/latest-github-actions-supply-chain-attack-spotbugs-reviewdog-tj-actions

[7] NIST, "CVE-2025-30066 Detail," National Vulnerability Database, Mar. 2025. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2025-30066

[8] CISA, "Supply Chain Compromise of Third-Party GitHub Action CVE-2025-30066," CISA Alerts, Mar. 18, 2025. [Online]. Available: https://www.cisa.gov/news-events/alerts/2025/03/18/supply-chain-compromise-third-party-github-action-cve-2025-30066

[9] GitHub, "GHSA-mcph-m25j-8mfq Advisory," GitHub Security Advisories, Mar. 2025. [Online]. Available: https://github.com/advisories/GHSA-mcph-m25j-8mfq

[10] Semgrep, "The tj-actions Supply Chain Attack," Semgrep Blog, Mar. 2025. [Online]. Available: https://semgrep.dev/blog/2025/the-tj-actions-supply-chain-attack/

Protecting your CI/CD pipeline doesn't have to be overwhelming. Whether you need a workflow audit, secrets rotation plan, or a full supply chain security review, our team helps small and mid-sized businesses build resilient development operations. Schedule a free consultation →

ELI10: How Hackers Poisoned a Popular GitHub Tool and Stole Thousands of Passwords

TL;DR

  • Hackers secretly changed a popular coding tool used by 23,000+ projects so it would steal passwords and secret keys.
  • 218 projects had their secrets stolen and written where anyone could read them.
  • The trick: the hackers were patient. They spent months sneaking through three different projects before reaching their real target.
  • The fix is simple: always lock your tools to an exact version that can't be secretly swapped out.

What's a Supply Chain Attack?

Imagine you're building with LEGO. You don't make every brick yourself—you trust that the bricks in the box are real LEGO bricks. A supply chain attack is when someone sneaks a fake brick into the box at the factory. It looks normal, but it does something bad when you use it.

Software developers do the same thing. They use building blocks (called "Actions" on GitHub) made by other people to help automate their work. Over 23,000 projects trusted a building block called tj-actions/changed-files to help check which files changed in their code [1][2].

What Did the Hackers Do?

In March 2025, hackers secretly swapped out that trusted building block with a poisoned version [1]. The poisoned version did its normal job—but it also quietly copied every secret password and key it could find, scrambled them in a code (double-base64 encoding), and wrote them into a public log file. That's like writing your house key code on a billboard [2][4].

The stolen secrets included passwords for cloud services (AWS), code-sharing platforms (npm, PyPI), server access keys (SSH), and more [2].

How Did They Pull It Off?

The clever part: the hackers didn't attack their real target directly. According to Wiz Research, they played a long game through three different projects [6]:

  1. Step 1 (November 2024): They tricked a project called SpotBugs into running their code, which let them steal a maintainer's access key.
  2. Step 2 (March 11, 2025): They used that stolen key to sneak into another project called reviewdog/action-setup.
  3. Step 3 (March 14, 2025): From reviewdog, they finally reached tj-actions/changed-files and poisoned every single version of it—from v1 all the way through v45.0.7 [1][4].

It's like breaking into a neighbor's house to steal their key to the office building to get into the vault. One key opened the next door.

How Was It Caught?

A security tool called Harden-Runner, built by StepSecurity, noticed something weird on March 15, 2025—the building block was making network calls it had never made before [5]. The U.S. government's cybersecurity agency (CISA) officially flagged it as a known threat on March 18, 2025, assigning it CVE-2025-30066 with a severity score of 8.6 out of 10 [7][8].

How Do You Stay Safe?

The main lesson is simple: don't trust labels that can be changed. Version tags like @v3 are like sticky notes—anyone with access can peel them off and stick them on something else. Instead, use the exact fingerprint of the code (called a "commit SHA"), which can never be faked or moved [4][10].

Here's what smart teams do:

  • Lock every tool to its exact fingerprint (commit SHA) so no one can swap it out.
  • Give tools only the minimum permissions they need—if a tool only needs to read code, don't give it permission to write.
  • Watch what your tools do at runtime with monitoring tools that catch unexpected behavior [5].
  • Rotate secrets regularly—change your passwords and keys on a schedule so stolen ones expire quickly.

These steps are straightforward, and they go a long way toward protecting what you've built.

References

[1] Wiz Research, "New GitHub Action Supply Chain Attack: reviewdog/action-setup," Wiz Blog, Mar. 2025. [Online]. Available: https://www.wiz.io/blog/new-github-action-supply-chain-attack-reviewdog-action-setup

[2] BleepingComputer, "GitHub Action supply chain attack exposed secrets in 218 repos," BleepingComputer, Mar. 2025. [Online]. Available: https://www.bleepingcomputer.com/news/security/github-action-supply-chain-attack-exposed-secrets-in-218-repos/

[4] NIST, "CVE-2025-30066 Detail — tj-actions/changed-files," National Vulnerability Database, Mar. 2025. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2025-30066

[5] StepSecurity, "Harden-Runner Detection: tj-actions/changed-files Action Is Compromised," StepSecurity Blog, Mar. 2025. [Online]. Available: https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised

[6] Wiz Research, "Latest GitHub Actions Supply Chain Attack: SpotBugs → reviewdog → tj-actions," Wiz Blog, Mar. 2025. [Online]. Available: https://www.wiz.io/blog/latest-github-actions-supply-chain-attack-spotbugs-reviewdog-tj-actions

[8] CISA, "Supply Chain Compromise of Third-Party GitHub Action CVE-2025-30066," CISA Alerts, Mar. 18, 2025. [Online]. Available: https://www.cisa.gov/news-events/alerts/2025/03/18/supply-chain-compromise-third-party-github-action-cve-2025-30066

[7] NIST, "CVE-2025-30066 Detail," National Vulnerability Database, Mar. 2025. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2025-30066

[10] Semgrep, "The tj-actions Supply Chain Attack," Semgrep Blog, Mar. 2025. [Online]. Available: https://semgrep.dev/blog/2025/the-tj-actions-supply-chain-attack/

Want help making sure your team's build tools are locked down? We help small and mid-sized businesses audit their CI/CD pipelines and fix exactly these kinds of risks. Book a free consultation →

Ready to strengthen your security?

Talk to lilMONSTER. We assess your risks, build the tools, and stay with you after the engagement ends. No clipboard-and-leave consulting.

Get a Free Consultation