The GitHub ecosystem has faced a serious wake-up call. A recent supply chain attack involving the widely-used GitHub Action tj-actions/changed-files exposed sensitive secrets across at least 218 repositories. While that’s a small percentage of the 23,000+ projects that rely on this action, the security implications are still deeply concerning—especially when many of the affected repositories are highly popular.
What Happened in the GitHub Supply Chain Breach?
On March 14, 2025, attackers added a malicious commit to tj-actions/changed-files. The injected code captured and dumped CI/CD secrets from the GitHub Runner Worker into the workflow logs. If these logs were set to public—which many projects do for transparency—anyone could access and read those secrets.
This malicious injection was likely made possible by a compromised GitHub personal access token (PAT). That PAT was associated with another action, reviewdog/action-setup@v1, which is believed to have been the original point of compromise in a chained supply chain attack.
Why This Attack Matters
Even though only 218 repositories confirmed secret leakage, the blast radius is massive. Endor Labs tracked the exposure window between March 14, 4:00 PM UTC, and March 15, 2:00 PM UTC. In that period, 5,416 repositories used the compromised action, and 614 of those executed it at least once.
Of those, 218 printed secrets directly into their logs. Many others avoided disaster by following best practices, such as referencing a commit SHA instead of a mutable version tag.
What Kind of Secrets Were Exposed?
The exposed credentials varied by project, but the most commonly leaked secrets included:
- GitHub Install Access Tokens
- AWS Credentials
- npm Tokens
- DockerHub Access Keys
While GitHub tokens typically expire within 24 hours, tokens for third-party services like AWS could remain valid unless manually rotated—leaving systems vulnerable to follow-up attacks.
Supply Chain Risks Beyond GitHub
What makes this attack especially alarming is its demonstration of how fragile the software supply chain really is. One weak link in the form of a single compromised action or token can quickly cascade into widespread exposure.
There are still unanswered questions about how many other GitHub Actions might have been compromised through the reviewdog breach. Security teams are now investigating if additional GitHub repositories were silently affected beyond those identified.
Lessons for DevOps and Security Teams
Developers using GitHub Actions should act quickly:
- Rotate All Secrets Immediately: Especially if your project used the compromised action during the exposure window.
- Avoid Mutable Tags: Always reference GitHub Actions by their specific commit SHA.
- Limit Workflow Permissions: Minimize what actions can access within your CI/CD pipeline.
- Restrict Workflow Logs: Keep them private to prevent unintended credential exposure.
- Adopt GitHub’s Hardening Guidelines: Follow security best practices outlined by GitHub to safeguard your workflows.
Protecting CI/CD Pipelines from Supply Chain Attacks
This incident reinforces the importance of continuous security auditing. Dependencies and third-party tools—especially in CI/CD pipelines—must be treated as potential attack vectors.
Many open-source developers rely on trust when pulling in GitHub Actions. However, the reviewdog and tj-actions compromise proves that even trusted packages can be turned malicious.
Organizations must invest in pipeline observability, automated secret scanning, and immediate alerting systems to respond swiftly to similar events.
A Glimpse Into Attacker Strategy
Attackers likely targeted projects with high GitHub star counts, forks, or visibility. Endor Labs discovered some repositories involved had over 350,000 stars and 60,000+ forks. The goal? Use these popular repos to spread compromised artifacts or dependencies downstream in a larger supply chain attack strategy.
If successful, such a campaign could reach thousands of end-users indirectly.
