Supply chain attacks are becoming more prevalent each day, particularly targeting open-source components. Due to the nature of the open-source ecosystem, anyone (!) can contribute to a project. While this openness is generally beneficial, malicious actors may exploit it for harmful purposes.

The recent supply chain attack on the widely used GitHub Action tj-actions/changed-files resulted in the exposure of secrets from numerous repositories. We have been actively educating our customers on effective mitigation strategies to counter these vulnerabilities so let’s explore how this attack happened, the necessary steps to mitigate such risks, and what we have learned.

This recent compromise of tj-actions/changed-files once again demonstrated that CI pipelines are a critical attack vector, emphasizing the need for organizations to take appropriate security measures.

How does the attack work?

The attack is triggered after the changed-files step runs in the pipeline. First, a crafted shell script executes, downloading a dropper from GitHub Pages, which dumps memory from /proc files and extracts secrets.

What is the impact?

The attack has been identified by Step-Security and the malicious version of the `***changed-files***` action has been removed quickly. The secrets on public repositories were then viewable by everyone in the workflow logs, obfuscated as a double-encoded base64 payload. Currently, there has been no exfiltration of secrets to an attacker-controlled server observed; the secrets were only observable within the affected repositories.

What to do?

• To check if your organization is using this action, use this GitHub query. As the malicious code prints the obfuscated secrets to the workflow logs, begin by looking at public repositories.
• Check your workflow logs for double base64 encoded strings.
• Regularly rotating secrets is a common security practice and widespread attacks like this are a good reminder to do so.
• Supply chain attacks like this often have larger goals. Using branch protection rules and repository controls are essential to limit and isolate such attacks.

How to prevent it?

• GitHub advises the following when using third party actions:
  • Pin actions to a full length commit SHA
  • Audit the source code of the action
  • Pin actions to a tag only if you trust the creator
• Monitor CI pipelines for anomalous behaviour (kntrl)
• Use allow-list to allow access to only trusted pages. GitHub shares meta IP ranges allowing access to only will prevent untrusted network connections

How can Invicti ASPM help you?

In response to this and similar threats, we have been developing kntrl, an open-source eBPF agent that aims to bolster the security of CI pipelines. You can configure kntrl with OPA rules to allowlist certain IP ranges or domains to limit network capabilities of a CI runner.

Below, you can see how it can be used to limit CI runner to only allow a sample package repository, effectively prevent tj-actions/changed-files to download memory dump step to carry out its attack.

If you would like to see kntrl in action, you can visit https://kntrl.dev to see how you can use it as well as contribute to the project. You are also welcomed to join us for our Arsenal session at BlackHat Asia on 3 April.

References

• https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised
• https://sysdig.com/blog/detecting-and-mitigating-the-tj-actions-changed-files-supply-chain-attack-cve-2025-30066/
• https://www.wiz.io/blog/github-action-tj-actions-changed-files-supply-chain-attack-cve-2025-30066