Overview
In March 2025, a major supply-chain attack compromised the popular GitHub Action tj-actions/changed-files, used by roughly 23,000 repositories.
The malicious update caused CI/CD secrets, like API keys, tokens, AWS credentials, npm/Docker credentials and more, to be dumped into build logs. For projects whose logs were publicly accessible (or visible to others), this meant secrets were exposed to outsiders.
A subsequent review estimated that at least 218 repositories confirmed leaked secrets.
What Happened
On March 14, 2025, attackers pushed a malicious commit to the tj-actions/changed-files repository. They retroactively updated several version tags so that all versions (even older ones) referenced the malicious commit, meaning users did not need to explicitly update to “vulnerable” version: their existing workflows were already poisoned. The compromised action included code that, when run during CI workflows, dumped the GitHub Actions runner process memory into workflow logs, exposing secrets, tokens, environment variables, and other sensitive data. On March 15, 2025, after the breach was detected, GitHub removed the compromised version and the action was restored once the malicious code was removed.
Because many projects rely on GitHub Actions and many developers use default tags (like @v1) rather than pinning to commit SHAs, the attack had a broad reach, potentially impacting any workflow that ran the action during the infection window.
How It Happened
- Supply-chain compromise – Attackers first compromised a bot account used to maintain the action (the @tj-actions-bot), gaining push privileges.
- Malicious commit & tag poisoning – They committed malicious code that dumps secrets, then retroactively updated version tags so all previous and current versions were tainted.
- Execution during CI/CD workflows – When any affected repository ran its CI workflow using the action, the malicious code executed and printed secret data into build logs.
- Secrets exposed – Logs could contain GitHub tokens, AWS credentials, npm/Docker secrets, environment variables, and other sensitive data — instantly readable by anyone with access to the logs.
- Wide potential blast radius – Given the popularity of the action, thousands of repositories were at risk, even those unaware of the change, underscoring the danger of trusting widely-used dependencies without lock-down.
Possible Impact & Risks
- Secret leakage – CI/CD secrets, including API keys, cloud credentials, tokens, exposed publicly. Attackers could use these for cloud account access, code or package registry abuse, infrastructure compromise, or further supply-chain attacks.
- Compromise of downstream systems – With stolen credentials, attackers could breach production environments, publish malicious packages, or manipulate deployment pipelines.
- Widespread supply-chain distrust – The breach erodes trust in open-source automation tools and GitHub Actions. Projects relying on third-party actions must now treat them as potential risk vectors.
- Developer & enterprise exposure – Both open-source and private organizations using the compromised action may be impacted, especially if they exposed logs publicly or reused leaked secrets across systems.
Recommendations
If you use GitHub Actions, especially third-party ones, here are essential steps to protect yourself:
- Audit your workflows – Identify if your repositories referenced tj-actions/changed-files, especially via mutable tags (e.g. @v1). If yes, treat credentials used in those workflows as potentially compromised.
- Rotate all secrets – Tokens, API keys, cloud credentials, registry credentials) that were used during the period between March 14–15, 2025.
- Pin actions to immutable commit SHAs – Rather than version tags, to avoid retroactive tag poisoning.
- Review all third-party actions before adding to workflows, and prefer actions from trusted authors with minimal permissions.
Use least-privilege tokens and ephemeral credentials in CI/CD, avoid granting broad access via long-lived secrets.
- Restrict access to workflow logs, especially for public repositories, avoid storing sensitive data in logs.
- Enable secret-scanning and auditing for CI/CD pipelines, watch for suspicious logs or leak indicators.
- Treat automation agents and CI identity (bots, actions) as non-human identities (NHIs) – apply the same governance, monitoring, and security hygiene as for real user accounts.
How NHI Mgmt Group Can Help
Incidents like this underscore a critical truth, Non-Human Identities (NHIs) are now at the center of modern cyber risk. OAuth tokens, AWS credentials, service accounts, and AI-driven integrations act as trusted entities inside your environment, yet they’re often the weakest link when it comes to visibility and control.
At NHI Mgmt Group, we specialize in helping organizations understand, secure, and govern their non-human identities across cloud, SaaS, and hybrid environments. Our advisory services are grounded in a risk-based methodology that drives measurable improvements in security, operational alignment, and long-term program sustainability.
We also offer the NHI Foundation Level Training Course, the world’s first structured course dedicated to Non-Human Identity Security. This course gives you the knowledge to detect, prevent, and mitigate NHI risks.
If your organization uses third-party integrations, AI agents, or machine credentials, this training isn’t optional; it’s essential.
Final Thoughts
The March 2025 breach of tj-actions/changed-files underlines a harsh but clear truth: software supply chains, including CI/CD tools and automation frameworks, are first-class attack surfaces. A single compromised action can leak secrets, expose credentials, and undermine trust in entire ecosystems.
For developers, organizations, and security teams, the lesson is urgent and unavoidable: never treat dependencies or automation tools as inherently safe. Always enforce inventory, least-privilege, version pinning, secret hygiene, and regular audits, especially for machine identities, third-party code, and CI/CD pipelines.
