Over the past weekend, security researchers discovered that the popular GitHub Action tj-actions/changed-files has been compromised. Malicious code added to the action attempts to extract secrets from CI/CD workflows, posing a significant security threat to thousands of repositories. The incident has been assigned an official CVE (CVE-2025-30066) to track it.
What is GitHub Actions?
GitHub Actions is a powerful automation tool that enables developers to streamline their CI/CD pipelines. Developers use it to automate tasks such as running tests, deploying applications, and managing workflows directly within their GitHub repositories.
This powerful tool can also be a problematic one. Over the years we have seen multiple malicious exploitations of it such as typosquatting—as explained in detail here.
What is tj-actions/changed-files?
While developers can write their own custom Actions, it is common practice to use pre-existing open-source Actions to perform common steps during a workflow, such as checking out a repository’s code, installing required development tools and packages, and more.
The tj-actions/changed-files action is widely used in GitHub workflows, with over 23,000 repositories integrating it. It detects file changes in pull requests, allowing workflows to selectively run actions based on modified files. Developers use it to optimize testing and scanning processes by targeting only changed files.
What happened?
On March 12, 2025, a malicious commit was introduced into the tj-actions/changed-files repository, which impacted the Action’s functionality. Once the vulnerability was reported, GitHub blocked the repository and it remained unavailable for several hours in order to prevent more users from being exposed to it. As of writing this article, the malicious commit has been removed from all versions of the Action, and it is available on GitHub once again.
Malicious code details:
- The attacker injected a Node.js function containing base64-encoded instructions.
- This function downloaded a Python script that scanned the memory of the GitHub Runner for credentials.
- The script dumped secrets into the GitHub Action build logs.
- In a separate instance (Flank project), exfiltration occurred via a POST request to a GitHub Gist.
- Most version tags were retroactively updated to point to the malicious commit (0e58ed8671d6b60d0890c21b07f8835ace038e67).
Who was affected?
Public repositories:
Any public repositories using tj-actions/changed-files between March 12, 2025, 00:00 UTC and March 15, 2025, 12:00 UTC is high risk. Secrets may have been exposed in public logs.
Private repositories:
While slightly lower risk, private repositories using the compromised action should assume potential secret exposure.
The difference between the public and private repositories is because, if the repository is private, the secrets are being dumped but an attacker from the outside doesn’t have access to the output from the execution of the action.
A little about supply chain attacks:
Supply chain attacks occur when an attacker finds a vulnerability somewhere in a process the victim is using. It can be a vulnerability in a supporting package used in the victim’s product, or, as we saw here, a vulnerability in the GitHub action the public is using—this isn’t a vulnerability in the victim’s environment per-se, but in a process the victim is using.
Mitigating and preventing supply chain attacks is a bit tricky—security specialists need to always be aware of the packages and dependencies being used in their environment, and take precautionary measures, such as pinning dependencies to a SHA256 and having an incident response plan should a supply chain issue arise.
How to mitigate the issue
To mitigate the issue:
- Search for
tj-actions/changed-filesin your codebase and remove all instances. - In case your project has used this action – Rotate all credentials immediately. If your project used this action, secrets may have been leaked.
- Delete compromised logs. Even if using a private repo, leaked secrets in logs could still pose a risk.
- Check runner logs for leaks. Any secret referenced in your job could have been compromised.
- Audit past workflow runs for suspicious outbound network requests.
Preventing future attacks
To help prevent future attacks:
- Ensure your version of
tj-actions/changed-filesisn’t affected and use the newest version, or revert to an older version as needed. - Pin all GitHub Actions to commit SHAs, instead of relying on version tags.
- Use GitHub’s allow-list feature to restrict the actions that can be used in workflows.
- Regularly audit workflows to detect unexpected changes.
In the recent hours, owners of the project on github have published a fix to the problem and the malicious commits affecting the tj-actions/changed-files repository have been removed, and all affected tags and branches have been restored, except for versions v45.0.5 through v45.0.9, which now point to the latest commit on main.
A security audit was conducted across all tj-actions repositories, leading to the introduction of tag protection rules to prevent unauthorized updates.
The incident was linked to a compromised Personal Access Token (PAT) associated with the tj-actions-bot account, though GitHub could not determine how the PAT was compromised. In response, the PAT has been revoked, authentication has been upgraded to use a passkey, and the bot’s permissions have been minimized. To further enhance security, signed commits are now required for all contributions.
Moving forward, PATs will no longer be used for any projects in the tj-actions organization to prevent similar incidents.
Final thoughts
This isn’t the first security incident involving tj-actions/changed-files. About a year ago, researchers identified a vulnerability (CVE-2023-51664) that allowed command injection via changed filenames, enabling attackers to execute arbitrary code. You can find details on that past issue here.
These incidents underscore the risks of third-party GitHub Actions. Developers must audit dependencies, pin safe versions, and monitor network behavior to catch suspicious activity before it leads to a security breach. By implementing these best practices, teams can strengthen the security of their CI/CD pipelines and minimize exposure to supply chain attacks.
How can Orca help?
Apart from the known advantages Orca has with detecting possible attack paths—by showing the user exactly which packages are being used and deployed on their assets, and which vulnerabilities they are exposed to—our experts at Orca Security have promptly created a special alert covering this vulnerability. The alert helps customers detect any assets exposed to this vulnerability and see instructions to quickly remediate the issue and keep their environment safe.
About the Orca Cloud Security Platform
Orca offers a unified and comprehensive cloud security platform that identifies, prioritizes, and remediates security risks and compliance issues across AWS, Azure, Google Cloud, Oracle Cloud, Alibaba Cloud, and Kubernetes. The Orca Cloud Security Platform leverages Orca’s patented SideScanning™ Technology to provide complete coverage and comprehensive risk detection.
Learn More
Interested in discovering the benefits of the Orca Platform? Schedule a personalized 1:1 demo, and we’ll demonstrate how Orca can help you command your cloud to identify, prioritize, and remediate risks.
