Blast Radius of the tj-actions/changed-files Supply Chain Attack
Analysis of the tj-actions/changed-files GitHub Actions compromise, assessing the impact and damage from the attack.
Analysis of the tj-actions/changed-files GitHub Actions compromise, assessing the impact and damage from the attack.
Analysis of the tj-actions/changed-files GitHub Actions compromise, assessing the impact and damage from the attack.
Analysis of the tj-actions/changed-files GitHub Actions compromise, assessing the impact and damage from the attack.
Analysis of the tj-actions/changed-files GitHub Actions compromise, assessing the impact and damage from the attack.
.png)
The recent attack on the GitHub Action tj-actions/changed-files raised a lot of attention in regard to software supply chain attacks – specifically regarding the security of CI/CD pipelines.
The general theme of many blog posts and comments is that tens of thousands of repositories use the GitHub Action. However, not all of them are necessarily affected, so we set out to better understand the actual damage caused by the attack, i.e. the number and type of secrets leaked.
TL;DR
We drilled down into repositories that depend on tj-actions/changed-files, the workflow runs executed during the critical timeframe of 24 hours, and the actual secrets leaked.
This analysis shows that the scale of the compromised repository secrets is not as big as anticipated. Apart from a few dozen credentials for DockerHub, npm or AWS, “only” GitHub install access tokens were leaked, which are relatively short-lived, thus, less valuable for attackers.
Still, the impact for the 218 affected repositories can be dramatic, so we informed the respective owners to rotate their secrets and check for malicious activity.
Drilling down
The original incident report claimed that the GitHub Action tj-actions/changed-files is used in tens of thousands of repositories. This number has been repeated by multiple sources. At first sight, this number sounds scary, but it is important to understand that not all repositories using tj-actions/changed-files were affected, i.e. not all of them leaked sensitive secrets in workflow logs, which could be harvested by attackers.
Let’s drill down step-by-step to see how bad the situation really is:
1) Repositories with workflow definitions that use tj-actions/changed-files
Using GitHub’s code search, we were able to identify 5,416 repositories across 4,072 distinct owners/organizations with YAML files that reference the targeted GitHub Action tj-actions/changed-files.
Some of those repositories are highly popular, with as many as 353K stars and 63K forks.
Note, however, that the code search has several limitations [6], especially its restriction to the default branch, typically main or master, so the actual number may be higher. Also note that this search only covers workflow definitions that directly depend on this action, not ones that transitively depend on it.
The following chart shows that 4,389 (81%) out of the 5,416 repositories only contain one workflow definition referencing tj-actions/changed-files, but 10 repositories contain 10 or more of such workflow definitions.
2) Repositories that ran the respective workflow during the timeframe
However, in order to leak secrets into the log, the respective workflows must have been executed in the respective timeframe. To determine the timeframe, we added 1 hour buffers to the times indicated by the original incident report [1], which resulted in a 24 hour timeframe from 2025-03-14, 15:00 UTC (when the malicious commits happened) to 2025-03-15, 15:00 UTC (when GitHub blocked access to the action).
Out of those 5,416 repositories, only 614 repositories (11%) ran one or more of their affected workflows during the relatively short timeframe of 24 hours. Most of them (533) ran the respective workflows between 1 and 10 times, but a few outliers even more than 50 times (with the maximum of 237 runs).
3) Workflow jobs that printed secrets to the log
And yet, having executed the action does not necessarily mean that any credentials were printed to the console log. Some repositories followed best-practice recommendations [7] and referenced the commit SHA instead of a mutable tag. Others were run before the attacker tampered with all of the version tags such that they point to the malicious commit (which only happened around 2025-03-14, 23:00 UTC according to the original incident report [1]).
Whether or not the malicious version of the action was run can be checked by looking at the log of the setup step, which is the first step run and downloads all the actions. In case a log contains an entry like follows, with the malicious commit SHA in brackets, the compromised version was run.
In the above case, the workflow definition referenced the tag “v45”, which the attacker pointed to the malicious commit. Because Git tags are mutable and can change over time, pinning the commit SHA is generally considered a security best-practice.
In a few dozen cases, however, the workflow definition itself directly referenced the malicious commit, which looks as follows in the log:
Overall, out of the 614 repositories that executed the GitHub action, only 218 leaked secrets to the console log (see chart below) with a total of 72 different names.
The vast majority are GitHub “install access” tokens made available as GITHUB_TOKEN to actions, and which can be used during workflow execution time for authentication [8]. They expire when a job finishes or after a maximum of 24 hours, which makes them less valuable for attackers compared to long-lived secrets such as GitHub personal access tokens (one of which was used by the attacker to compromise the tj-actions repository in the first place).
The bar chart below shows the frequency of leaked GITHUB_TOKENs as a separate item, whereas all the other secrets were grouped according to the service or kind. The group “GitHub other”, for example, contains personal access tokens, and the group “Docker” contains DockerHub user names, tokens and passwords.
Conclusion
The initial scale of the supply chain attack sounded scary, considering that tens of thousands of repositories depend on the GitHub Action.
However, drilling down into the workflows, their runs and leaked secrets shows that the actual impact is smaller than anticipated: “Only” 218 repositories leaked secrets, and the majority of those are short-lived GITHUB_TOKENs, which expire once a workflow run is completed.
In other words, in order to exploit a leaked GITHUB_TOKEN, attackers need to perform malicious activities during the workflow run. This could be achieved by intentionally pausing the workflow execution as exemplified in this blog [2], however, this behavior has not been observed in this particular case.
While the overall scale of the attack is smaller than anticipated, the impact of leaked secrets on the individual repositories can of course be dramatic. Credentials for services DockerHub or npm provide the opportunity for further supply chain attacks.
Endor Labs can help
Endor Labs customers can enable CI scanning for GitHub Actions and search their direct and transitive dependencies for the presence of tj-actions/changed-files. In fact, Endor Labs is currently the only tool that can do transitive dependency analysis for GitHub Actions.
Contact us if you’d like to learn more about CI/CD security, or securing your GitHub Actions workflows.
References
- Harden-Runner detection: tj-actions/changed-files action is compromised (Step Security)
- CVE-2023-49291 and More – A Potential Actions Nightmare (Adnan Khan)
- tj-actions/changed-files issue #2464 (GitHub)
- CVE-2025-30066 (CVE Database)
- Changed Files Action (GitHub Marketplace)
- GitHub API Search Code (GitHub Docs)
- Security Hardening for GitHub Actions (GitHub Docs)
- Automatic Token Authentication (GitHub Docs)
