A supply chain attack on the popular GitHub Action tj-actions/changed-files caused many repositories to leak their secrets over the weekend. Wiz Research has discovered an additional supply chain attack on reviewdog/actions-setup@v1, that may have contributed to the compromise of tj-actions/changed-files. At this point we believe this is a chain of supply chain attacks eventually leading to a specific high-value target.
TL;DR
As we previously reported, the widely used GitHub Action
tj-actions/changed-fileswas compromised with a malicious payload that caused affected repositories to leak their secrets in logs. By extension,tj-actions/eslint-changed-fileswas also compromised at the same time, as it relies ontj-actions/changed-files.Based on a lead from Adnan Khan, Wiz Research has identified that the v1 tag of the
reviewdog/action-setupGithub Action was compromised in the lead up to the tj-actions incident. Immediate response is necessary to mitigate the risk of credential theft and CI pipeline compromise.The maintainers of tj-actions have disclosed that a compromised Github Personal Access Token (PAT) was the root cause that allowed attackers to modify the repository.
We believe that it is likely the compromise of
reviewdog/action-setupis the root cause of the compromise of the tj-actions-bot PAT.tj-actions/eslint-changed-filesusesreviewdog/action-setup@v1, and thetj-actions/changed-filesrepository runs thistj-actions/eslint-changed-filesAction with a Personal Access Token. The reviewdog Action was compromised during roughly the same time window as the tj-actions PAT compromise.Because the compromise of
reviewdog/action-setuphas not previously been disclosed and appears to have been remediated incidentally, there is ongoing risk of reoccurence. This could lead to a repeat compromise oftj-actions/changed-files.Wiz has disclosed this issue to reviewdog and GitHub.
What is the impact on affected organizations?
As we saw with tj-actions, the compromised reviewdog action injected malicious code into any CI workflows using it, dumping the CI runner memory containing the workflow secrets. While this is the same outcome as in the tj-actions case, the payload was distinct and did not use curl to retrieve the payload. Instead, the payload was base64 encoded and directly inserted into the install.sh file used by the workflow.
On public repositories, the secrets would then be visible to everyone as part of the workflow logs, though obfuscated as a double-encoded base64 payload. As of now, no external exfiltration of secrets to an attacker-controlled server were observed; secrets were only observable within the affected repositories themselves.
We believe reviewdog Action’s v1 tag was pointed to a malicious commit on March 11th between 18:42 and 20:31 UTC, before the v1 tag reverted to point at an old commit. The attacker may have force-pushed back to the older commit to cover up the compromise, which implies they achieved a narrow goal and desired to stay stealthy. (edit: an earlier draft of this post attributed this to an automated version bump, and has been edited based on feedback from a reviewdog maintainer)
There is still a risk of actions being cached and secrets that have already been leaked because of this compromise, so action is still required.
Which products are affected?
As of March 17, 2025, only one tag (v1) of the reviewdog/action-setup Action was found to be affected. Customers who were using a hash-pinned version of reviewdog/action-setup or who were pinned to a different tag would not be impacted.
However, this Action is then used as a component of numerous other actions from reviewdog, including:
reviewdog/action-shellcheck
reviewdog/action-composite-template
reviewdog/action-staticcheck
reviewdog/action-ast-grep
reviewdog/action-typos
Customers who were using other impacted reviewdog/actions could be impacted, regardless of the version of that action.
How did this happen?
The investigation is still ongoing. We can tell the attacker gained sufficient access to update the v1 tag to the malicious code they had placed on a fork of the repository. The reviewdog Github Organization has a relatively large contributor base and appears to be actively adding contributors through automated invites. This increases the attack surface for a contributor’s access to have been compromised or contributor access to have been gained maliciously.
We’ll update this blogpost as new information comes to light.
Which actions should security teams take?
Use this Github query to find references to the affected GitHub Actions in your organization's repositories (replace
yourorgwith the name of your Github organization).If any affected repositories are identified, note the impacted workflow job and navigate to the "Actions" tab or click "View Runs". Check for any GitHub Actions that include the affected compromised component and ran during the relevant timeframe.
Navigate to the relevant workflow job, and expand the “Run reviewdog/action-setup@v1” step. If you see a line titled “🐶 Preparing environment ...”, the malicious code was run. Check whether there is a double-encoded base64 string within. If one exists, then that means that the malicious payload was successfully executed, and the impact depends on whether the repo is public or private: If the repo is public, then it means that the secrets in the string were publicly leaked in workflow logs, and we highly recommend rotating them as soon as possible. Otherwise, if the repo is private, then that means the secrets were not leaked publicly, but you should still consider rotating them.
Note that if your repository was impacted but the only secrets exposed were GitHub tokens beginning with the prefix ghs_, these are short-lived tokens that automatically expire within 24 hours or once the workflow job has completed. Consequently, unless a job was interrupted and failed to finish, there is limited long-term risk from the exposure of a ghs_ token alone.
Additionally, if your workflow does not explicitly reference custom secrets (for example, token: ${{ secrets.MYSECRET }}), it is unlikely that sensitive secrets were compromised as a result of this incident. The primary risk lies in the potential exposure of explicitly referenced custom secrets within affected workflows.
What should I do if my organization is affected?
Stop using the impacted actions immediately and replace them with a safer alternative if possible.
Remove all references to the actions across all branches of your repositories, not just the main branch, to prevent potential execution in other branches.
Rotate any leaked secrets as soon as possible. Deleting the relevant workflow will also remove all the logs, which can prevent further exposure of the secrets. However, it is also recommended to download workflow logs from the exposure window before deleting anything.
How can I prevent this sort of risk in the future?
As recommended by GitHub, pin all GitHub Actions to specific commit hashes instead of version tags to mitigate against future supply chain attacks.
Audit past workflow runs for suspicious activity. Check logs for unusual outbound network requests, and prioritize reviewing repositories where CI runner logs are publicly accessible, as secrets may have been exposed in logs.
Use GitHub’s allow-listing feature to block unauthorized GitHub Actions from running and configure GitHub to allow only trusted actions.
How can Wiz help?
Wiz Sensor customers with Sensor deployed on CI workloads can detect malicious activity related to this attack, such as process memory dumping.
Wiz Defend customers with GitHub audit logs enabled are protected against potential secondary malicious activities facilitated by the abuse of any compromised credentials, such as deleting workflow logs or merges by unusual bot use.
Wiz customers can also refer to the Threat Intel Center advisory for this attack, which includes additional capabilities and will be updated as new ones are added.
