In yet another blow to the security of open-source software, a widely used GitHub Actions package has been compromised, potentially exposing credentials from over 23,000 organizations, including major enterprises. Attackers infiltrated the maintainer account of the tj-actions/changed-files package, injecting credential-stealing code that propagated across repositories globally.
A Silent, Pervasive Attack
The compromised package is part of the tj-actions suite, a popular collection of automation scripts leveraging GitHub Actions for CI/CD (Continuous Integration/Continuous Deployment) processes. The breach was discovered last Friday, but signs suggest unauthorized modifications may have been made earlier. The attackers manipulated versioning tags to direct users to a malicious file that copied and logged server memory contents—exposing critical secrets in public logs.
Security experts have long warned about the risks inherent in GitHub Actions. This attack exploited precisely that vulnerability, as many developers referenced tj-actions tags instead of cryptographic hashes, allowing the compromised versions to be executed across numerous repositories.
Widespread Exposure of Sensitive Data
StepSecurity, the cybersecurity firm that first detected the breach, identified the attack through an anomaly in network traffic—an unexpected outbound endpoint that raised red flags. Their analysis suggests the attacker likely compromised a credential used by the @tj-actions-bot to push updates to the repository. The bot’s password has since been rotated and protected by a passkey, a more secure authentication method endorsed by the FIDO Alliance.
Security firm Wiz corroborated the severity of the breach, stating that "dozens of repositories operated by large enterprise organizations" were affected, with leaked secrets including AWS access keys, GitHub Personal Access Tokens, npm tokens, and private RSA keys. Given the scale of the attack, security teams are scrambling to determine the potential downstream impact.
GitHub and Maintainers Respond
In response, GitHub took swift action to suspend compromised accounts and remove the malicious code. A GitHub spokesperson stated, "Out of an abundance of caution, we suspended user accounts and removed the content in accordance with GitHub’s Acceptable Use Policies. We reinstated the account and restored the content after confirming that all malicious changes have been reverted and the source of compromise has been secured."
Dimitri Stiliadis, CTO of Endor Labs, underscored the broader implications of the attack, warning that "the attacker was likely looking to compromise the software supply chain for other open-source libraries, binaries, and artifacts created with this." He further stressed the urgency of auditing repositories for indirect dependencies, as even organizations that do not explicitly use tj-actions may be impacted through transitive dependencies.
How Developers and Organizations Should Respond
For organizations utilizing GitHub Actions, immediate steps must be taken to assess and mitigate potential compromise, according to Stiliadis:
Identify Affected Repositories: Conduct a search across all repositories to determine if tj-actions/changed-files was in use. Even if direct references are absent, investigate dependencies that may include the compromised package.
Remove tj-actions/changed-files Immediately: GitHub has removed the package, meaning any CI pipelines relying on it will break. Ensure it is removed from all repository branches, as latent references could still pose risks.
Audit Past CI/CD Workflow Logs: Check for suspicious outbound network requests and exposed credentials. Prioritize reviewing logs from public repositories, as attackers may have harvested secrets directly from CI/CD outputs.
Rotate Any Exposed Secrets: If any credentials may have been compromised, disable and regenerate them immediately. This includes AWS keys, GitHub tokens, and any other environment variables stored in repositories.
The Bigger Picture: Open Source Security in Crisis
The tj-actions breach is just the latest in a series of high-profile supply-chain attacks targeting open-source ecosystems. Last year, security researchers discovered a sophisticated backdoor in xz Utils, a core Linux compression library, narrowly preventing what could have been a catastrophic attack. These incidents highlight the growing vulnerabilities within open-source software supply chains, where trust is implicitly placed in maintainers and contributors without rigorous verification mechanisms.
As Stiliadis cautions, "This is an important reminder that the surface of open-source dependencies is much broader than just packages and libraries—it includes your secrets, CI code, containers, and everything else developers use to build software."
The question now is not just how organizations will respond to this breach, but how long it will take for affected repositories to revoke compromised secrets and implement security best practices. In the meantime, the damage could range from minor disruptions to full-blown data breaches, depending on the attacker's motives and how the stolen credentials are exploited.
While GitHub and the open-source community work to strengthen defenses, this incident serves as a stark warning: in today’s software landscape, every component—no matter how seemingly insignificant—can be a potential attack vector. And as supply-chain attacks grow more sophisticated, the need for proactive security measures has never been more urgent.