🚨 tj-actions/verify-changed-files COMPROMISED

[sanjay7178]

Recently, several of tj-actions GitHub Actions have been compromised with vulnerabilities, including tj-actions/verify-changed-files used by this template:

lab-website-template/.github/workflows/update-url.yaml

Line 57 in d515175

uses: tj-actions/verify-changed-files@v18

lab-website-template/.github/workflows/update-citations.yaml

Line 73 in d515175

uses: tj-actions/verify-changed-files@v18

https://github.com/airvitap/airvitap.github.io/actions/runs/13873209466/job/38822331341

References

• https://semgrep.dev/blog/2025/popular-github-action-tj-actionschanged-files-is-compromised/
• https://nvd.nist.gov/vuln/detail/CVE-2023-52137
• https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised
• https://news.ycombinator.com/item?id=43367987
• GHSA-ghm2-rq8q-wrhc

[vincerubinetti]

Thank you for bringing this to my attention. This was a pretty bad incident. I've added a few more references to your original issue, and reformatted it.

It seems that GitHub took the action down quite quick after the vulnerability exploit went into effect; within roughly 24 hours. And now the action is restored, without the vulnerability.

Here is my assessment.

---

Most likely risk for Lab Website Template users

The compromised action could leak repository secrets and use them maliciously. There are many possible risks, but here is the most likely one, given how the template is set up.

One of your workflow run's GITHUB_TOKEN could've been leaked in its log. This token is unique to each workflow run, and expires immediately after the workflow run completes. In order for an attacker to do something malicious, they would've had to look at one of your workflow logs between March 14th and 15th, and while it was still running, use it to commit something malicious to your repo, such as ads/malware/tracking/explicit content/etc.

Further, I believe that an attacker would've had to be targeting your repo specifically. This is because I don't think there would be any way -- either via the GitHub API, scraping, Google searching, etc. -- for an attacker to find any public repository on GitHub currently running the compromised verify-changed-files action, at least not within the few-minute window required. They'd have to be looking specifically at your repo, and wait for a workflow to run.

Because of all this, even this most-likely scenario is still not very likely, in my estimation.

Less likely risks

These shouldn't apply to 99% of template users, because it would involve doing something uncommon with your repo or actions set up, or otherwise require very unlikely circumstances.

Instead of committing something malicious to your repo, an attacker could have leaked other sensitive info in your secrets or repo for other malicious purposes.

For example, perhaps your repo is private and has sensitive information. An attacker could've used the leaked GITHUB_TOKEN to see that info. However, this would've required an attacker to have access to your private repo (i.e. someone on your team), so they would presumably already have some level of privileged access to the sensitive info anyway.

As another example, maybe you've added an API key secret so you can deploy your website to Google Cloud instead of GitHub Pages. This could've been leaked to an attacker for them to gain access to your Google Cloud.

Also, if you have modified or added other workflows such that they take longer or do different things, that may have given an attacker more time to use the GITHUB_TOKEN before it expired.

Summary

If your template ran any GitHub Actions between March 14th and 15th 2025, check your repository for any suspicious commits during those times. If you don't see anything, you are most likely fine.

How we plan to handle this

I will review #313 and possibly merge it into a new version of the template. For now, since the vulnerability has been patched in the upstream action, template users should be safe. That is, any damage that could've been done has already been done, regardless of whether we implement the change or not.

I recall looking into dorny/paths-filter before and it having some limitation that made it not appropriate for the template, but I will investigate it again. I will make the switch if at all possible, though, because it has more stars than tj-actions/verify-changed-files, and is perhaps more trustworthy.

In some sense, though, software that has experienced a crisis could be more safe than one that hasn't, because the former could be bolstered to enhance security whereas the latter could be more complacent about it.

[sanjay7178]

wild 😅 , your response is too verbose, thanks for the information

[sanjay7178]

If that's more serious making a quickest solution would be better , because many of your lab template used by organizations would have suffered

[vincerubinetti]

Actually, it appears that only tj-actions/changed-files was compromised, not tj-actions/verify-changed-files. I didn't notice this at first. I can't find anything about the latter being compromised, and I'd assume that the sources involved (GitHub, semgrep, the actions maintainer, etc.) would've done a due diligence check that one as well.

Further, to the best of my understanding, the exploit only comes into play when using the result of the action inside run block, which we are not doing.

Thus, this security incident shouldn't impact the template at all.

---

Regarding tj-actions's response to this, they seem to have taken it seriously:

tj-actions/changed-files#2464
tj-actions/changed-files#2482
https://github.com/tj-actions/changed-files

---

Regarding switching to dorny/paths-filter, I'd point to this issue and the many open unresolved issues:

dorny/paths-filter#262

Though I have confidence tj-actions won't make the same mistake again, to be safe, I'll be pinning the version to a commit hash.

---

Regarding the workflow failure that @sanjay7178 originally reported:

Download action repository 'tj-actions/verify-changed-files@v18' (SHA:eb6d385c0e52fb28e2f6b70e15c835cb3cbfff17)

This was just due to all of tj-actions being temporarily being taken down.

[vincerubinetti]

Because of my above message which concludes there is no risk to the template, I'm going to close this.

Further, I had thought about pinning the version of the tj-actions actions I've used, but have decided against it:

1. I don't actually think their actions are more likely to be compromised in the future than any of the other actions we use, so if I'm going to version-pin theirs, I'd want to version pin all of them. Nothing technically wrong with this, but more verbose and manual.
2. Pinning a version wouldn't have actually prevented this incident, since IIRC, it involved pointing an existing version tag to a different (malicious) commit. Commit-hash-pinning would fix this though.
3. Although (hash) pinning would ensure a known/existing commit is being used, it would on the flip side prevent users from getting any future bug fixes. In my experience, most users of this template never update their template versions after the first time they clone it, which makes me nervous that they'd never update their pinnings and get the newest and safest versions.
4. Following the thought above: Although this incident was serious, it was noticed, taken down, and remedied very quickly, since a lot of eyes are on it. If all template users had pinned action versions, and a vulnerability was discovered in one of them, perhaps at a much later date, it would definitely take the average template user much longer to fix the pinning. (This is assuming the vulnerability wasn't so bad that the maintainers would remove the tag entirely, but at that point we could assume they'd also fix the "latest" tag, making the pinning moot).