🚨 Popular GitHub Action tj-actions/changed-files is compromised

Popular GitHub Action tj-actions/changed-files has been compromised (GitHub issue) with a payload that appears to attempt to dump secrets, impacting thousands of CI pipelines. This isn’t the first security issue with tj-actions/changed-files—see prior vulnerability CVE-2023-51664.

What you should do

1. Find out where you're affected

   1. The simplest way to find this is to grep for tj-actions in your codebase.

   2. If you're on GitHub, look at the results of this query, replacing YOURORG with your organization's name on GitHub: 
      https://github.com/search?q=org%3A<YOURORG>+uses%3A+tj-actions%2F&type=code

   3. Arguably, Semgrep is overkill for this case. But Lewis Ardern on our team wrote a Semgrep rule to find usages of tj-actions, which you can run locally (without sending code to the cloud) via: semgrep --config r/10Uz5qo/semgrep.tj-actions-compromised. And if we find more information about what tags & commits are affected, we can update the rule over time to become more precise about whether or not you could be impacted. At time of writing, it looks like all versions are compromised.

   4. For users of Semgrep AppSec Platform, we recommend placing the detection rule in blocking mode immediately: visit the rule, click “add to policy”, and select “blocking mode.”

2. Stop using tj-actions/changed-files immediately. Switch to a safer alternative or inline your file-change detection logic.

   1. Just removing it from the main branch of your repository won’t be enough — it could still run on other branches depending on how your actions are configured. So you need to remove it from all branches to be safe.

   2. As an alternative, GitHub has a feature that lets you allow-list GitHub actions so you can ensure it won’t run, even if it’s still in your code.

      1. You’ll need a list of GitHub Actions used at your org. Run this query on your codebase:

         $ semgrep -e 'uses: $ACTION' -l yaml --json .github  | jq -r '.results[].extra.metavars["$ACTION"].abstract_content' | grep -vE '^(actions/|docker://|[.]/[.]github/|tj-actions/)' | awk -F'@' '{print $1 "@*,"}' | sort | uniq
         DataDog/synthetics-ci-github-action@*,
         actions-rs/toolchain@*,
         astral-sh/setup-uv@*,
         aws-actions/amazon-ecr-login@*,

      2. Remove tj-actions/changed-files from the list of GitHub Actions.

      3. Go to GitHub settings and configure like this at:
         https://github.com/semgrep/semgrep-app/settings/actions
         

   3. Generally, pin all GitHub Actions to specific commit SHAs (rather than version tags) you know are safe. In this case, it appears that all versions are compromised.

   4. Audit past workflow runs for signs of compromise. Check logs for suspicious outbound network requests. Prioritize repos where your CI runner logs are public, as secrets are dumped to stdout in the payload.

Affected versions

At time of writing (2025-03-14T23:55:00Z), we assessed by inspecting tag pointers in the source repo that all versions of tj-actions/changed-files are compromised. Users may verify with git tag --points-at 0e58ed8 . See commit 0e58ed8 in https://github.com/tj-actions/changed-files.

Further reading

• StepSecurity’s Incident Analysis

• https://github.com/tj-actions/changed-files/issues/2463

• CVE-2023-51664

• GitHub Advisory Database: CVE-2025-30066

• tj-actions changed-files release v0.46.01

Update March 17th 2025 12:24pm PT

Over the weekend the gist that was used in the compromised attack chain to retrieve credentials and later echo them in the log was removed and now returns a 404 not found. GitHub have released a GHAS advisory on the incident and tj-actions has reverted all tags to no-longer point to the compromised commit, in addition to releasing a new version (v46.0.1).

The recommended next steps are:

1. Investigate if you have any repositories that did use tj-actions, you likely need to rotate any secrets that were made public in the CI build logs, using the steps above in this blog post

   1. Any tj-actions that leveraged tags would need to be investigated e.g.,
      tj-actions/changed-files@v45 should be reviewed

   2. Any tj-actions versions that used the compromised commit
      tj-actions/changed-files@0e58ed8671d6b60d0890c21b07f8835ace038e67 should be reviewed

2. Upgrade all workflow actions to use the latest release immutable commit:
   tj-actions/changed-files@2f7c5bfce28377bc069a65ba478de0a74aa0ca32
   or use the latest @v46tag.

Semgrep recommends where possible to use immutable commits to prevent issues and, as always, you should aim to keep on the latest version to keep ahead of any reported vulnerabilities in earlier versions of the library.

Update March 18th 2025 08:00AM PT

Further research performed by Wiz has uncovered further compromise to reviewdog/action-setup@v1, in the lead up to the tj-actions incident. Some of the other reviewdog actions depended on this action, so for a speculated timeline of March 11th between 18:42 and 20:31 UTC these actions were compromised, before the v1 tag reverted to point at an old commit via an automated processed. See this Reviewdog issue, Supply Chain Attack on reviewdog GitHub Actions during a specific time period.


Semgrep customers should see if you used any of these actions:

• reviewdog/action-setup@v1

• reviewdog/action-shellcheck

• reviewdog/action-composite-template

• reviewdog/action-staticcheck

• reviewdog/action-ast-grep

• reviewdog/action-typos

• tj-actions/eslint-changed-files

• tj-actions/changed-files

1. Find out where you're affected

   1. The simplest way to find this is to grep for reviewdog/ tj-actions in your codebase

   2. If you're on GitHub, look at the results of this query, replacing YOURORG with your organization's name on GitHub: https://github.com/search?q=org%3AYOURORG+(reviewdog%2Faction-setup%40v1+OR+reviewdog%2Faction-shellcheck+OR+reviewdog%2Faction-composite-template+OR+reviewdog%2Faction-staticcheck+OR+reviewdog%2Faction-ast-grep+OR+reviewdog%2Faction-typos+OR+tj-actions%2Feslint-changed-files+OR+tj-actions%2Fchanged-files)+language%3Ayaml+path%3A%2F^\.github\%2Fworkflows\%2F%2F&type=code

   3. Our team wrote a Semgrep rule to find usages of reviewdog actions, which you can run locally (without sending code to the cloud) via: semgrep --config r/d8UqKj5/semgrep.reviewdog-actions-compromised

   4. We updated the Semgrep rule to find usages of tj-actions, to search for tj-actions/eslint-changed-files which you can run locally (without sending code to the cloud) via:
      semgrep --config r/10Uz5qo/semgrep.tj-actions-compromised

   5. For users of Semgrep AppSec Platform, we recommend placing both the detection rule in blocking mode immediately : visit the rule, click “add to policy”, and select “blocking mode.”

2. Find compromised CI logs

   1. You should look at your Github runner logs where these actions were included and look for either:

      1. 🐶 Preparing environment …

      2. changed-files

   2. Check whether there is a double-encoded base64 string within.

   3. You should follow the similar steps above in this blog post to rotate any leaked secrets, and prevent further compromise.