Threat Assessment: GitHub Actions Supply Chain Attack: The Compromise of tj-actions/changed-files

Executive Summary

A recent compromise of the GitHub action tj-actions/changed-files and additional actions of the reviewdog organization, illustrate the risks associated with dependencies in continuous integration/continuous delivery (CI/CD) pipelines. This incident underscores how attackers can exploit vulnerabilities in third-party actions or dependencies to compromise software supply chains, potentially resulting in unauthorized access, data breaches or code tampering.

Overview of Attack

GitHub Actions is a CI/CD platform that helps users automate their development pipeline. Additionally, individual GitHub actions, which have the same name, are reusable workflow components that other pipelines can utilize. The tj-actions/changed-files GitHub action was recently compromised, allowing attackers to access sensitive workflow secrets within code that uses this action. This GitHub action is used by over 23,000 GitHub repositories.

The compromise was first identified on March 14, 2025, when security researchers detected suspicious activity made by the action. The attackers injected a payload that dumped CI/CD runner memory data, exposing sensitive environment variables and secrets directly within workflow logs.

A lead provided by Adnan Khan suggested that the compromise of the tj-actions/changed-files action originated in the compromise of another repository belonging to another GitHub organization: reviewdog/action-setup. This compromise also impacted the tj-actions/eslint-changed-files action. Further investigation found that additional actions belonging to the reviewdog organization were hijacked. Until the investigation is complete, any repository or action of the reviewdog organization is considered risky to use.

Recommended Mitigations

We focus here on detection and prevention steps from the perspective of the consumers of the compromised tj-actions/changed-files action and the actions belonging to the reviewdog organization. The community can also learn from the compromise of the actions and their hosting repository.

The detailed mitigations and recommended actions below include immediate steps for affected users, such as:

• Identify usage
• Review workflow logs
• Rotate secrets
• Investigate malicious activity

We also share ways to make long-term security improvements related to this issue, as well as information on how Palo Alto Networks cloud security products can assist with protecting against this and similar security risks.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Overview of the Attack Flow

The attack appears to have been executed through unauthorized modifications to the tj-actions/changed-files GitHub repository, where the action’s code is stored. Instead of altering the source code in a highly visible manner, the attackers modified tagged releases to reference a dangling commit that contained a malicious payload with the SHA1 hash of 0e58ed8671d6b60d0890c21b07f8835ace038e67. By altering historical version tags, the attackers ensured that existing workflows pulling nearly all release versions of the action would execute the compromised code.

This attack appears to have been conducted using a leaked GitHub Personal Access Token (PAT) linked to the @tj-actions-bot account. GitHub has stated that it is unable to determine how this PAT was compromised, but proactive steps have been taken to mitigate further risks.

The attackers used the @tj-actions-bot account’s PAT to push the malicious commit, while impersonating another user account named renovate[bot], to make the commit appear as if it originated from a legitimate user. A lack of security controls in the tj-actions/changed-files repository – such as requiring signed commits and not implementing branch and tag protection rules – allowed the operation to succeed.

The malicious code executed a Python script designed to extract CI/CD secrets from the runner's memory, subsequently printing them in the workflow logs. Located in public repositories, these logs are accessible to anyone, enabling the attackers – and anyone else – to disclose the workflow secrets.

The attack was detected by StepSecurity’s researchers, who reported the incident to the maintainers of the compromised repository.

Later on, Adnan Khan shared his research, suggesting that a compromise of another GitHub organization (reviewdog) made the compromise of the tj-actions/changed-files action possible. Attackers did this by pushing malicious code to the reviewdog/action-setup action, which was used indirectly by the tj-actions/changed-files action via its dependent action tj-actions/eslint-changed-files. This implied that the action tj-actions/eslint-changed-files is compromised as well.

Further investigation found that additional actions belonging to the reviewdog organization were compromised. Until the investigation is complete, any repository or action of the reviewdog organization is considered risky to use.

Security Implications

The issue impacted all GitHub Actions workflows that met the following criteria:

• Referencing one of the tj-actions/changed-files or tj-actions/eslint-changed-files actions
• Pointing to one of the vulnerable tags or branches
• Executed between 9 a.m. PT March 14, 2025, and 3 p.m. PT March 15, 2025
• Any actions created by the reviewdog organization
  • While this is a broad instruction, we will continue to monitor this situation and update as soon as possible with more granular instructions

Most git tags of the action were modified to point to the malicious commit. This mainly affects public repositories, as the payload prints the runner’s secrets to the workflow log, making them available for anyone to consume.

If the payload had been instructed to send the stolen secrets to an external location instead of printing it to the workflow logs, the impact of the attack would likely have been much greater. This behavior raises questions regarding the nature and intentions of this attack that have yet to be answered.

More than 23,000 repositories use the tj-actions/changed-files action in their workflows. We investigated this action and found that it is a direct dependency in more than 60 public GitHub actions. Also, many of the 23,000 dependencies are repositories that host additional GitHub actions, and their workflows use the compromised actions as part of their build flow. These findings indicate that an even greater supply chain attack could be waged through the Actions dependency tree, potentially affecting a much larger repository base.

Once the compromised action is used in a GitHub Actions workflow, the malicious code runs in the agent. This in turn leads to the exposure of secrets stored in the agent’s memory to the workflow logs, which are printed double-encoded in Base64 text. CI/CD secrets are usually highly sensitive, as CI/CD pipelines pave the path from code to runtime, meaning that it is common to see secrets with high privileges providing access to broad cloud assets within the pipelines.

GitHub Actions workflows also generate a unique GITHUB_TOKEN in every run. This token is used to interact with the repository, and could be assigned with read and write permissions to the repository. It is likely that these tokens were exposed by the malicious action. An attacker gaining access to a GitHub Actions workflow with ‘write’ permission can push malicious code into the repository, which could potentially reach the production environment.

Mitigations and Recommended Actions

Immediate Steps for Affected Users

• Identify usage: Search for the tj-actions/changed-files action and other actions mentioned above in your repositories to determine whether and where it has been used.
• Review workflow logs: Examine past workflow runs for evidence of secret exposure double-encoded in Base64 text, especially if the logs are public.
• Rotate secrets: Revoke and regenerate any credentials that may have been exposed. Ensure that all API keys, access tokens and deployment credentials are refreshed.
• Investigate malicious activity: If you encounter any signs that the compromised action has been executed, investigate further for any signs of malicious activity.

Long-Term Security Improvements

• Govern third-party services in use: Implement vetting procedures to ensure external actions receive approval before being integrated into workflows.
• Implement strict Pipeline-Based Access Controls (PBAC): Reduce the permissions granted to GitHub Actions workflows to the minimum necessary. Use fine-grained and short-lived tokens instead of long-term and broadly scoped secrets.
• Pin GitHub actions: Instead of referencing GitHub actions by tag or branch (e.g., @v3 or @main), pin actions to a full-length commit SHA-1 hash to ensure the code is not changed by a malicious actor.

To learn more about protecting your Version Control Systems (VCS) and CI/CD systems, we recommend reaching out to the OWASP Top 10 CI/CD Security Risks project.

Conclusion

The tj-actions/changed-files compromise underscores the risks inherent in CI/CD pipelines, and those posed by third-party dependencies. As adversaries increasingly target these environments to gain quick access to production assets, organizations must adopt a security-first approach when incorporating external tools into their workflows.

The likelihood of supply chain attacks can be significantly reduced by implementing strict security measures, such as:

• Pinning dependencies
• Using verified actions
• Adopting PBAC

Teams must prioritize security and take proactive steps to safeguard their automation pipelines against potential threats.

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Palo Alto Networks Protections and Mitigations

For existing customers, Prisma Cloud identifies executables and GitHub actions that are executed in their pipelines. The product identifies tools used by the organization, allowing customers to readily find whether the vulnerable action is in use, and in which pipelines. Customers can also implement out-of-the-box policies to protect against associated risks, as detailed below.

As customers are upgraded from Prisma Cloud to Cortex Cloud, they can benefit from all existing protections, enhanced with the ability for users to allow or restrict the usage of tools running in their pipelines, and to track deployment of forbidden tools – as shown below in Figure 1.

Through various out-of-the-box policies designed to identify vulnerable areas within CI/CD environments, customers can help prevent similar future attacks, and reduce the impact of a potential breach.

Relevant Out-of-the-Box CI/CD Policies for Palo Alto Networks Customers

Palo Alto Networks customers should refer to the following policies in their environments, and mitigate the issues in accordance with the recommendations provided in each policy.

• Unpinned GitHub actions: Unpinned GitHub actions are mutable. This allowed the attackers to push a malicious version of the tj-actions/changed-files action as an existing tag, thereby introducing poisoned code that could be executed in consumers’ pipelines – even if the attacker did not change the tag’s version. Any consumer using an unpinned version of this action could be vulnerable to this malicious code execution, if the compromised version is executed.
• Unrestricted usage of GitHub actions allowed in the repository/across the organization: Allowing all GitHub actions to be used in the repository regardless of their author exposes the organization to the risk of a malicious actor taking control over an Action’s repository, as happened in the recent breach. GitHub allows restricting allowed actions solely to Enterprise actions, preventing the execution of external actions.
• Excessive GitHub actions pipeline permissions on the repository: When a pipeline is executed, GitHub creates a short-lived GITHUB_TOKEN for interacting with the repository. If permissions granted to the GITHUB_TOKEN are not defined in the pipeline’s YAML file, the pipeline’s default permissions are set to either read and write (default setting in older repositories) or read repository contents for all scopes, without considering the specific requirements of the workflow.

Another security concern is when either read-all or write-all permissions are defined in a pipeline, as this grants the GITHUB_TOKEN permissions across all scopes. As the GITHUB_TOKEN was leaked from memory in the attack, attackers who gained access to a GitHub Actions pipeline with excessive permissions could take full advantage and exploit the permissive GITHUB_TOKEN.

• Github actions access cloud providers using insecure long-term credentials: Long-term credentials that are intended for use by GitHub Actions workflows to authenticate to a cloud provider account are stored on GitHub as a secret. This increases the impact of credential theft, as stolen credentials can be used long after a workflow run is complete.

GitHub supports the OpenID Connect (OIDC) authentication protocol to replace long-term credentials with short-lived access tokens. Using OIDC, the GitHub Actions workflow can request a short-lived token directly from the cloud provider; this token expires automatically when the workflow run ends.

In addition, OIDC allows more granular control over how secrets can be used. For example, it is possible to filter access to tokens when the request originates in specific protected branches or environments.

Palo Alto Networks Offers Comprehensive Protections Against Future Vulnerabilities in Code

Cortex Cloud Application Security helps customers build secure apps and stop threats before they emerge. By unifying code, pipeline, runtime, application context and third-party findings within a single risk, policy and automation engine, teams get the visibility and control that they need to prevent issues at the source. Cortex Cloud Application Security combines context-aware, AI-based prioritization with a prevention-first approach to empower teams to accelerate secure deployments. This helps organizations to identify the security gaps in their environments, and to mitigate and reduce the impact of the most significant threats.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
• UK: +44.20.3743.3660
• Europe and Middle East: +31.20.299.3130
• Asia: +65.6983.8730
• Japan: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 00080005045107