GitHub Action tj-actions/changed-files, Supply-Chain Attack: The Complete Guide

March 18, 2025 update: Thanks to leads from Adnan Khan and investigative efforts by Rami McCarthy from Wiz, new evidence suggests that the compromised GitHub Action reviewdog/action-setup may have leaked the token eventually used to breach tj-actions/changed-files.

• Suspected Chain Reaction:
  • The malicious reviewdog/action-setup (tagged v1) was used by tj-actions/eslint-changed-files.

• • Since tj-actions/eslint-changed-files is part of the CI for tj-actions/changed-files, the leaked token from reviewdog/action-setup may have allowed attackers to compromise tj-actions/changed-files.
• Recommended Immediate Check: If your workflows used any reviewdog Actions (including reviewdog/action-setup)—directly or indirectly—review your configurations and logs for suspicious commits.
• While this chain of events is not fully confirmed, it provides a plausible explanation of how the incident may have unfolded.

A major software supply chain attack recently struck the widely used tj-actions/changed-files GitHub Action—an alarming development that has impacted over 23,000 repositories. A malicious commit stealthily harvested secrets from the GitHub Actions runner environment, jeopardizing credentials, tokens, and other sensitive data.

Key Highlights

• What Happened? A malicious payload was introduced to the popular tj-actions/changed-files Action, exposing sensitive secrets by printing them to the build logs.
• Widespread Impact (March 14-15): Any repository executing tj-actions/changed-files during this window likely leaked sensitive credentials, including API tokens and passwords.
• Repository Taken Offline: Though unclear whether GitHub or the maintainer initiated the removal, the repository went offline, preventing further exploitation.
• Restoration: The Action was later restored after the malicious commit was removed, but not before 23,000+ repositories were potentially affected.
• Mitigation Steps: Identify and remove the compromised Action from your workflows, rotate exposed secrets, and closely monitor your CI/CD pipelines for unusual or suspicious behavior.
• Ongoing Risks: This incident highlights how quickly attackers can weaponize popular open-source tools, emphasizing the importance of robust supply chain security.

If you want a deeper understanding of what happened, how to secure your CI/CD pipelines, and why you need an ASPM (Application Security Posture Management) platform to protect against runtime attacks, read on.

What is the tj-actions/changed-files GitHub Action?

The tj-actions/changed-files GitHub Action is a widely adopted tool that identifies which files have changed in a pull request or commit. By detecting modified files, teams can streamline their workflows—triggering tests, deployments, or other tasks only for the specific files impacted. This significantly improves efficiency in CI/CD pipelines.

Due to its popularity, nearly 23,000 repositories rely on this Action for day-to-day operations. Its broad adoption made it a prime target for attackers looking to exploit a trusted supply chain component.

What Happened?

Recently, a malicious commit was injected into the tj-actions/changed-files repository, specifically targeting secrets in the GitHub Actions runner environment. Attackers were able to collect critical credentials and tokens, posing a severe threat to any organizations and repositories that depended on this compromised version of the Action.

The malicious code focused on the Runner.Worker process, extracting secrets, passwords, and authentication tokens exposed during CI/CD jobs. In many instances, these secrets were likely leaked publicly, potentially granting malicious actors direct access to sensitive systems and internal services.

Quick Timeline of the Compromise

1. Malicious Commit Introduced (March 14, 16:57 UTC): Disguised as a Dependabot update, the malicious commit appeared in the Action’s repository.
2. Immediate Impact: With the commit in place, all Action tags started pointing to the compromised commit, meaning most repos referencing these tags were at risk.
3. Discovery of the Malicious Commit: A community issue highlighted suspicious activity, indicating the Action was exfiltrating environment variables and secrets.
4. Repository Taken Offline: Roughly 12 hours after the initial discovery, the repository became inaccessible, effectively halting new downloads of the compromised version. It remains unclear whether GitHub or the maintainer initiated the takedown.
5. Reinstating the Action (March 16): The malicious commit was reverted, and the repository was reactivated. Despite the fix, an estimated 23,000 repositories had already been exposed to the compromised Action.

Additional Note (March 18 Update): Evidence has emerged suggesting reviewdog/action-setup was compromised first, leaking a CI token that may have been used to breach tj-actions/changed-files. Because tj-actions/eslint-changed-files used reviewdog/action-setup, the token leakage likely spread via that chain. Although not fully confirmed, this progression aligns with similarities in the malicious commits observed in both repositories.

What is the Impact of the tj-actions/changed-files Compromise?

The biggest concern is that sensitive credentials—API tokens, passwords, SSH keys, or other environment variables—may have been leaked in build logs. If you used the compromised version of this Action and passed secrets (for example, via {{ secrets.TOKEN }}) to the GitHub workflow:

• Infrastructure at Risk: Attackers could pivot into your production environment or developer infrastructure using these exposed credentials.
• Data Exfiltration: Any secret or configuration data stored in environment variables might already be in malicious hands.

How Do I Know If My Repositories Are Affected?

1. Check Workflow Files Manually
   Look for references to tj-actions/changed-files in your .github/workflows/ directory.
2. Use GitHub Search
   If you have multiple repositories, run the following GitHub search query, replacing <orgname> with your organization name to find all usages.
3. Review Action Versions
   • Vulnerability arises if you pinned the Action to a branch name (e.g., tj-actions/changed-files@main), a tag (e.g., @v45), or a malicious SHA commit.
   • An example of a malicious SHA pin is tj-actions/changed-files@0e58ed8671d6b60d0890c21b07f8835ace038e67.
4. Audit CI/CD Logs
   Focus on runs triggered between March 14 and March 15, when the malicious commit was active. If your logs contain Base64-encoded strings or suspicious printouts of environment variables, you may have been compromised.

What Immediate Steps Should I Take to Mitigate the Risk?

1. Remove or Replace the Action

Even though the malicious code has been removed, it’s prudent to temporarily remove or replace tj-actions/changed-files until you finish investigating how the Action was compromised. Some community members created temporary forks with safe, pre-malicious code. Pay attention to side branches or older versions in your workflows.

2. Rotate Secrets

Any tokens, passwords, or environment variables used in the affected workflows should be considered compromised. Update these secrets in all relevant environments, including development, staging, and production.

3. Review Audit Logs

Look for unusual pipeline executions or suspicious commits. Keep an eye out for references to unknown external IPs, new files, or other unexpected changes.

4. Check for reviewdog Usage (March 18 Update)

• Don’t limit your investigation to reviewdog/action-setup; search for any references to the broader reviewdog ecosystem in your .github/workflows/ directory.
• If your workflows rely on tj-actions/eslint-changed-files, verify whether that Action is (or was) pulling in the malicious version of reviewdog/action-setup.
• As always, rotate potentially exposed tokens or secrets and carefully review your CI/CD logs for any suspicious activity.

How Can I Prevent Similar Supply Chain Attacks in the Future?

1. Pin Dependencies and Actions

Always pin GitHub Actions to a specific commit SHA or a trusted version tag. Many organizations that carefully pinned to a known safe SHA avoided the malicious update entirely.

2. Implement Runtime Monitoring

Static scanning tools alone may overlook malicious behavior triggered at runtime. Use real-time monitoring solutions to detect abnormal network calls, suspicious file modifications, and data exfiltration attempts within CI/CD jobs.

3. Set Strict Policies and Permissions

Limit the default permissions for your Actions to read-only whenever possible. In GitHub’s organization settings, you can also create an allow-list of approved Actions, preventing unvetted or unverified Actions from running in critical workflows.

How Cycode Helps Organizations Strengthen Their Software Supply Chain Security

1. Rapid Detection and Remediation with RIG

Cycode’s Risk Intelligence Graph (RIG) promptly locates where malicious or vulnerable Actions—like tj-actions/changed-files—are referenced in your environment. Using RIG, security teams can:

• Identify all pipelines and repositories using the compromised Action.
• Assess real risk (e.g., if SHA pinning was used, exposure is minimized).
• Verify whether a vulnerable workflow actually ran during the malicious timeframe, refining exposure assessments.
• Alert on new or existing pipelines referencing known vulnerable Actions.

2. CI/MON for Runtime Protection

CI/MON (cimon.build) adds real-time monitoring and defense for your CI/CD execution:

• Detect & Block suspicious network connections or exfiltration attempts.
• Analyze runtime behavior to halt malicious code injection.
• Gain Visibility into ephemeral runner processes, ensuring secrets remain secure.
• Prevent mode: Customers who enabled CI/MON’s prevent mode were protected, as it blocked unknown outbound connections (e.g., to gist.githubusercontent.com URL).

3. Proactive Risk Management

Cycode enforces strict policies around Actions, permissions, and CI/CD behavior:

• Restrict usage to verified Actions.
• Monitor workflow permissions and environment variables to reduce unnecessary exposure.
• Continuously scan code, dependencies, and pipelines for vulnerabilities, misconfigurations, and embedded secrets.

4. Automated Threat Intelligence Feed

Cycode integrates a threat intelligence feed that automatically correlates known malicious commits and compromised repositories with your existing pipelines. Through our automated alerts:

• Pinpoint which specific workflows or repositories might include vulnerable Actions.
• Provide immediate insight into the exact pipeline location of compromised dependencies.
• Deliver real-time security context to prioritize remediation.

5. Expertise in GitHub Actions Security

Cycode’s research team has:

• Discovered and disclosed vulnerabilities in major open-source projects like Bazel and Storybook.
• Developed Raven, an open-source CI/CD security analyzer.
• Published in-depth guides on securing GitHub and GitHub Actions.

With this expertise, Cycode helps you detect, analyze, and remediate threats in GitHub Actions—often before they escalate into full-blown incidents.

Conclusion

The tj-actions/changed-files breach is a blunt reminder that even the most trusted tools can be hijacked by a single malicious commit. This incident underscores an urgent truth: our software supply chain is only as strong as its weakest link. By thoroughly checking workflows, rotating leaked secrets, monitoring build logs, and fortifying pipelines with real-time security solutions like Cycode’s RIG and CI/MON, organizations can confidently navigate an ever-evolving threat landscape and keep their CI/CD processes on solid ground.

Additional Resources

• CI/MON – Real-Time CI/CD Runtime Protection
• Cycode Research: Injection Through GitHub Actions
• Raven – Open-Source CI/CD Security Analyzer
• Best Practices for Integrating with GitHub
• GitHub Issue Highlighting the tj-actions/changed-files Compromise
• cicd-leak-scanner – Open Source by Cycode Labs