The tj-actions/changed-files GitHub Action Supply Chain Attack

What happened

An attacker stole a token for the action's bot account, added a malicious commit and moved the release tags to it. StepSecurity reports that the attacker compromised a personal access token (PAT) for the @tj-actions-bot account and updated all release tags to the malicious commit, 0e58ed8671d6b60d0890c21b07f8835ace038e67.

The code ran a Python script that downloaded a memory-dump script from a GitHub gist. The script read the memory of the Actions Runner process through /proc/{pid}/mem and printed the secrets it found, Base64-encoded, into the workflow log. In public repositories, anyone can read the log.

Unit 42 traced the chain back further. According to Unit 42, the attacker first leaked a SpotBugs maintainer token through a pull_request_target workflow. It then reached the reviewdog action setup, and from there the token for tj-actions/changed-files. Unit 42 states that Coinbase's agentkit repository was the first target of the code.

StepSecurity dates the start of the incident to about 16:00 UTC on 14 March 2025. GitHub removed the action on 15 March at about 14:00 UTC. The maintainers restored the repository about eight hours later and cleaned the malicious code.

Vigilance compares the version you trust with the new one. A tag that now points to different code is a change in the files an action runs. Vigilance reports the file that gained a new capability. See the scan block below.

Affected versions

• tj-actions/changed-files through v45.0.7, according to the GitHub advisory. The advisory lists the vulnerable tags v1.0.0, v35.7.7-sec and v44.5.1 among them.
• Patched in v46.0.1.
• The window ran on 14 and 15 March 2025. Workflows that ran in that window and used a tag, not a commit SHA, are the ones to review.

Indicators of compromise

• Malicious commit: 0e58ed8671d6b60d0890c21b07f8835ace038e67.
• Outbound request to gist.githubusercontent.com, for the file memdump.py.
• A long Base64-encoded block in a workflow log, printed by the changed-files step.
• Workflow runs of the action on 14 or 15 March 2025.

How to check

Find every workflow that uses the action and see how it is pinned.

grep -rn "tj-actions/changed-files" .github/workflows

A line with a tag such as @v44 was exposed. A line that pins a full commit SHA from before the attack was not. Then open the logs of runs from 14 and 15 March 2025 and look for a large Base64 block in the changed-files step.

What to do now

1. Remove the action or update to v46.0.1. StepSecurity also offers a drop-in fork, step-security/changed-files@v45.
2. Review the logs of workflows that ran on 14 and 15 March 2025. Delete or restrict logs that show secrets.
3. Rotate every secret that those workflows can read. This includes cloud keys, tokens and SSH keys.
4. Pin actions to a full commit SHA, not to a tag.
5. Restrict which actions your organization can run. Use OpenID Connect for cloud sign-in instead of long-lived keys.

What Vigilance showed

Vigilance compares the version you trust with the new one and names the file that gained a new capability. The block below is rebuilt from the public reports in the words Vigilance prints. It is not a captured scan, because the malicious release is not redistributed.

files scanned: 66

HEADS UP  1 file can now do things the old version could not. The rest changed and gained nothing.

CHANGED    dist/index.js
           It now downloads from the internet, reads saved passwords and access keys and runs a hidden, encoded command. It did not before.

Sources

1. github.com/advisories/ghsa-mrrh-fwg8-r2c3
2. stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised
3. unit42.paloaltonetworks.com/github-actions-supply-chain-attack/