WEBINARSecure your AI agents in days, not weeks– Discover Polymer’s SecureRAG today!

Request a demo

Polymer

Download free DLP for AI whitepaper

Summary

  • A GitHub supply chain attack compromised tj-actions/changed-files, used by 23,000+ repositories, exposing CI/CD secrets.
  • Attackers hijacked a bot’s personal access token (PAT) to inject malicious code.
  • Leaked credentials include AWS keys, GitHub PATs, and RSA keys.
  • Affected users must rotate secrets, audit workflows, and update dependencies.
  • To prevent future attacks, pin dependencies to commit hashes and deploy real-time DLP tools to detect exposed secrets.

A widely used GitHub Action, relied upon by more than 23,000 repositories, has fallen victim to a supply chain attack, potentially exposing sensitive secrets from CI/CD build logs.

The compromised tool, ‘tj-actions/changed-files’, is a popular automation component within GitHub Actions, the platform’s continuous integration and delivery (CI/CD) system. It is used to streamline software development workflows.

Here’s a closer look at how the breach occurred, and what to do if your organization is impacted. 

How did the GitHub breach happen? 

On March 14, 2025, attackers successfully inserted a malicious commit into GitHub Action tj-actions/changed-files, embedding code that extracted CI/CD secrets from the runner worker process. 

These secrets—used to authenticate and manage access to various systems—were then leaked into the affected repositories. If workflow logs were publicly accessible, this effectively meant anyone could harvest and exploit the stolen credentials.

According to reports, attackers executed the attack by gaining control of a GitHub personal access token (PAT) linked to a bot account (@tj-actions-bot). This granted them privileged access to the tool. 

Once inside the repository, the hacker subtly modified the software to do more than its intended function—silently siphoning sensitive data from the machines running it. This was achieved by injecting a Node.js function containing base64-encoded instructions to execute a Python script. That script systematically exfiltrated CI/CD secrets from the Runner Worker process.

Many developers inadvertently ran the malicious code, exposing critical credentials. For public repositories, this meant that secrets—AWS access keys, GitHub PATs, npm tokens, private RSA keys, and more—were written in plaintext within workflow logs, making them easily accessible to attackers. 

How has GitHub responded? 

GitHub has confirmed that it has taken swift action to secure the compromised @tj-actions-bot account.

In a statement, GitHub said the bot account’s password has been updated, passkeys are now enforced, and its permissions have been restricted. Additionally, all future commits to the repository will now be cryptographically signed to prevent unauthorized modifications.

“The personal access token affected was stored as a GitHub action secret which has since been revoked,” said a GitHub representative. “Going forward no PAT would be used for all projects in the tj-actions organization to prevent any risk of recurrence.”

The tj-actions repository has since been restored, with GitHub publishing clear remediation steps for affected users:

  • Rotate any secrets that may have been exposed between March 14-15.
  • Review workflows for unexpected output under the ‘changed-files’ section.
  • If your workflows reference the compromised commit by SHA, update them immediately.
  • Ensure you are now using a tagged version (e.g., v35, v44.5.1).

Lessons learned 

This attack underscores the risk of blindly trusting third-party tools to effectively manage security. When using SaaS applications like GitHub, organizations must take additional steps to mitigate the exposure of sensitive data. 

First, GitHub Actions users must pin dependencies to specific commit hashes rather than relying on version tags. This simple yet critical step prevents bad actors from slipping malicious code into future updates of an action. By locking workflows to a known, trusted state, organizations can dramatically reduce the attack surface of their CI/CD pipelines.

Second, organizations should deploy real-time data loss prevention (DLP) solutions within GitHub. Tools like Polymer automatically scan repositories, comments, and commits to detect and secure exposed secrets, credentials, and dependency risks. More importantly, they can enforce security policies—blocking risky commits, requiring additional approvals, or rejecting pull requests before sensitive data is leaked.

With supply chain attacks becoming more frequent, organizations must remain vigilant and implement stronger security controls to protect their development environments. Secure your software supply chain today. Request a Polymer GitHub demo now.

Polymer is a human-centric data loss prevention (DLP) platform that holistically reduces the risk of data exposure in your SaaS apps and AI tools. In addition to automatically detecting and remediating violations, Polymer coaches your employees to become better data stewards. Try Polymer for free.

SHARE

Get Polymer blog posts delivered to your inbox.