The tj-actions/changed-files compromise could have been caught at three points: when version tags were moved to a malicious commit, when secrets appeared in build logs as an encoded blob, and upstream, when reviewdog/action-setup@v1 was compromised on 11 March 2025. Each check depends on knowing which third-party code runs inside your build pipeline and what secrets it can reach.
What happened to tj-actions/changed-files?
CISA says the tj-actions/changed-files Action, which detects which files changed in a pull request or commit, was compromised. GitHub’s advisory says attackers retroactively changed several version tags to point to a malicious commit, exposing CI/CD secrets in workflow logs. The advisory says the affected repositories numbered over 23,000. The full sequence is on our tj-actions supply chain incident page. There is no public attribution: the sources say “attackers” or “a threat actor” and name no group or country.
CISA says the compromise allows disclosure of secrets such as access keys, GitHub personal access tokens, npm tokens and private RSA keys. It was patched in version 46.0.1, and CISA added both related CVEs to its Known Exploited Vulnerabilities Catalog.
Where could the chain have been caught?
The lesson in the public record is that a version tag is not a promise. Attackers retroactively changed version tags, so a workflow that named a tag could end up running a different commit. The points below come from the sources, and each one is a place a control could have acted.
- Upstream compromisereviewdog/action-setup@v1 was compromised on 11 March 2025, 18:42 to 20:31 UTC
- Tags movedAttackers pointed several version tags at a malicious commit
- Secrets in logsSecrets were printed to workflow logs, possibly as a double-encoded base64 payload
How did the attack get into the build?
CISA says the tj-actions compromise was potentially enabled by a compromise of reviewdog/action-setup@v1 around the same time. The reviewdog maintainers later said a contributor’s personal access token had been compromised and used to overwrite the reviewdog tags, and that only the v1 tag was affected. They said the stolen token came from an attack on another repository.
The reviewdog maintainers also said that contributors to their action repositories were auto-invited to a team with write access, which had 118 members. For a buyer, this is the practical point: the people who can change code you run are not only the named maintainers of the Action you chose.
GitHub’s advisory for reviewdog says other reviewdog Actions that use action-setup@v1 were also compromised, whatever their version or pinning method. CISA lists five further reviewdog Actions that may be affected. Does your review cover what the Actions you picked depend on?
What did the malicious code do with your secrets?
GitHub’s advisory says the modified Action ran a malicious Python script. The script scanned memory for secrets, took them from the Runner Worker process, base64-encoded them and printed them in the Actions logs. In repositories with public workflow logs, those logs were publicly readable. The advisory says organizations with public repositories are at the highest risk.
CISA adds that secrets may be hidden as a double-encoded base64 payload. The advisory also says to review workflows run in the window and decode suspicious output before rotating secrets.
What should a security buyer ask about the pipeline?
The questions below follow from the stated facts. They are checks, not a claim about what any one organization did.
- Which third-party Actions run in our pipelines?CISA tells affected organizations to find all projects that used tj-actions/changed-files between 2025-03-12 00:00 UTC and 2025-03-15 12:00 UTC.
- Are they pinned to a full commit SHA?GitHub’s documentation says this is currently the only way to use an action as an immutable release.
- Can policy enforce the pinning?GitHub documentation says repository and organization policies can require full-length commit SHA pinning.
- Who can change the code we depend on?The reviewdog write-access team had 118 members.
- Who reads our build logs?Logs of public repositories were publicly readable.
- Did anything in the window print an encoded blob?Decode suspicious output first, then rotate.
What did the maintainers and CISA tell people to do?
CISA says to rotate all identified secrets immediately and treat them as compromised, and to check public repositories whose workflows ran the malicious commit for exposed keys and tokens. The tj-actions maintainers said on 15 March 2025 that the malicious commits were removed from all tags and branches and that tag protection rules were added to stop tags linked to unverified commits being pushed. They advise pinning dependencies to specific commit SHAs. The reviewdog maintainers disabled the automated inviter workflow, removed write access from most contributors and updated their repositories to reference Actions by commit SHA.
Note that the exposure window differs by source. GitHub’s advisory, NVD and the CVE record give 14 to 15 March 2025, while CISA tells organizations to check 12 March 00:00 UTC to 15 March 12:00 UTC. Which window did your log review cover?
Two linked pieces cover this from other angles: the Bybit theft and the cyber incidents of 2026.