On Friday, a supply chain attack compromised the widely used GitHub Action tj-actions/changed-files, exposing secrets from numerous repositories. This incident, assigned CVE-2025-30066, underscores the growing risks in software supply chains and highlights the need for stronger runtime security measures in CI/CD pipelines. The vulnerability was first reported by Step Security.

Note: this event is still ongoing, and not all details are known as of the time of this write up.

What is tj-actions/changed-files?

tj-actions/changed-files is a GitHub Action designed to detect which files have changed in a pull request or commit. It enables workflows to execute tasks conditionally based on file modifications, such as running specific tests or triggering deployments. Due to its usefulness, the action is widely adopted in open-source and enterprise repositories.

What Happened?

Attackers injected malicious code into the GitHub Action, allowing it to dump memory from CI/CD runners. This resulted in workflow secrets being exposed in logs, though there is no confirmed evidence of external exfiltration. The breach affected all versions of the action, as the attacker successfully modified every version tag.

What is Affected?

• Repositories using tj-actions/changed-files in their GitHub Actions workflows.
• CI/CD Pipelines that rely on the action for automation.
• GitHub Workflows where sensitive credentials are used, potentially exposing API keys, authentication tokens, and other secrets.

While repositories using hash-pinned versions (commit SHA references) were not immediately impacted, those that updated to a compromised hash during the attack window remain at risk.

What Should You Do?

To mitigate the risks associated with this attack, take the following steps:

1. Identify Usage: Search your repositories for references to tj-actions/changed-files in workflow YAML files.
2. Review Workflows: Audit workflows executed during the compromise window to determine potential exposure.
3. Inspect Logs: Check CI logs for double-encoded base64 strings, as they may contain leaked secrets.
4. Rotate Secrets: Immediately revoke and regenerate any secrets that may have been exposed.
5. Cache Clearance: Since GitHub Actions cache dependencies, ensure the compromised action is removed from the cache before redeploying.
6. Use Verified Actions: Whenever possible, rely on GitHub’s verified actions or self-hosted alternatives to reduce supply chain risks.

How Sweet Detects tj-actions/changed-files

Unlike traditional shift-left security tools that rely on known CVEs, IoCs, or predefined TTPs, Sweet detects threats based on baseline deviations—unusual behaviors that indicate an attack, even when no prior knowledge of the exploit exists.

As security researcher James Berthoty noted in his write-up about the CVE: 

"Sweet really impressed me with how it accurately captured everything that happened. I was especially happy with how it called it out as a memory dump attack."

This level of precision and clarity is what makes runtime security an essential layer of defense against modern supply chain threats.

The Growing Threat of Supply Chain Attacks

This incident highlights the increasing threats facing software supply chains, particularly within open-source ecosystems. Attackers continue to target widely used components to maximize impact. Developers and organizations must adopt a zero-trust approach to dependencies, regularly audit their supply chain, and enforce stricter security controls.

For additional details on securing your GitHub Actions workflows, refer to GitHub’s security documentation.

By proactively securing workflows and monitoring dependencies through runtime, organizations can reduce their exposure to supply chain attacks and better protect sensitive assets.

Why You Need Runtime Security to Detect These Attacks 

Shift-left supply chain security measures focus on pre-deployment controls, like scanning dependencies, enforcing software composition analysis, and implementing strict CI/CD policies. These are all crucial things to do but they sometimes fail to detect active compromises in real time. This is where runtime security becomes essential.

In the case of CVE-2025-30066, a runtime security approach could have detected:

• Memory Dumping and Unusual Process Behavior: Attackers injected malicious code to extract secrets from CI/CD runners. Sweet's runtime security continuously monitors process execution and memory access, flagging unauthorized memory reads that deviate from normal CI/CD behavior.
• Anomalous Network Traffic: If an attacker attempted to exfiltrate secrets, Sweet would detect unexpected outbound connections or data transmissions from CI/CD runners.
• Code Execution Anomalies: Runtime monitoring catches unauthorized script execution, command injections, and unexpected API calls within workflows.
• Secret Exposure Detection: Even if credentials were leaked into logs, Sweet’s runtime analysis can identify exposure patterns and alert security teams before exploitation occurs.

Want to learn more about Sweet? Book a demo today.