Wake-Up Call: tj-actions/changed-files Compromised NHIs

Cybersecurity threats are constantly evolving, targeting both human and non-human identities (NHIs). A recent incident involving the popular tj-actions/changed-files GitHub Action serves as a stark reminder of the importance of securing these often-overlooked machine identities. Detected by StepSecurity Harden-Runner, this compromise highlights the risks NHIs pose in the software development lifecycle and shows why strong security is needed and incident response practices.

Understanding the tj-actions/changed-files Incident

In March 2025, StepSecurity detected a critical security incident affecting the widely used tj-actions/changed-files GitHub Action, which is used in over 23,000 repositories. Attackers modified the action’s code and retroactively updated multiple version tags to point to a compromised commit. This malicious code was designed to dump CI/CD secrets from GitHub Actions build logs. If these workflow logs were publicly accessible, as is the case with public repositories, these secrets could be exposed to anyone.

The attack began around 9:00 AM PST on March 14, 2025. StepSecurity’s Harden-Runner identified the issue through anomaly detection when an unexpected network endpoint appeared in the workflow traffic. Further analysis revealed a malicious Python script downloading and executing to extract secrets from the GitHub Actions Runner’s memory.

GitHub Actions as Non-Human Identities

GitHub Actions and the secrets they utilize are prime examples of NHIs. These automated workflows, along with API keys, tokens, and service accounts, function autonomously but hold permissions to access and modify critical resources.

The tj-actions/changed-files incident illustrates the inherent risks associated with NHIs:

• Credential Exposure: The attack aimed to expose sensitive CI/CD secrets, which could be used for unauthorized access to connected systems. This aligns with NHI2:2025 - Secret Leakage in the OWASP Non-Human Identities Top 10.

• Vulnerable Third-Party NHI: The action is a third-party component integrated into numerous development workflows. Its compromise exemplifies NHI3:2025 - Vulnerable Third-Party NHI, where a seemingly trusted external element becomes a vector for attack. Organizations integrate such tools for efficiency but often overlook the security risks of their NHIs.

• Lack of Visibility and Monitoring: Without proactive security measures like Harden-Runner’s anomaly detection, the malicious activity could have gone unnoticed, potentially leading to widespread credential theft. This highlights the challenge of maintaining centralized visibility over NHIs.

Lessons Learned and the Critical Role of Incident Response

The tj-actions/changed-files incident reinforces key principles for strengthening NHI security, particularly in incident response:

• Assume Compromise: This incident reinforces an “Assume Leak” mindset. Organizations should assume NHIs may already be compromised and implement continuous monitoring.

• Early Detection Enables Swift Response: StepSecurity Harden-Runner detected the compromise early by identifying an unexpected network endpoint. Early detection is important for swift incident response and damage mitigation.

• Immediate Remediation Is Key: After detecting the compromise, StepSecurity quickly released a free, secure drop-in replacement (step-security/changed-files) to aid recovery. GitHub also removed and then restored the repository with the malicious code removed. This demonstrates the importance of predefined incident response playbooks.

• Communication and Transparency: StepSecurity promptly alerted users through a blog post and continuous updates, even hosting an Office Hour to answer questions. Clear and timely communication is critical during a security incident.

• Comprehensive Remediation Beyond Immediate Fixes: Replacing the compromised action is necessary, but so is identifying and revoking potentially exposed secrets. Organizations using the affected action were advised to review recovery steps immediately, which is why reliable remediation workflows matter.

• Third-Party Vetting and Incident Preparedness: Organizations must thoroughly vet third-party tools used in their pipelines and understand the permissions granted to NHIs. This includes evaluating the vendor’s own incident response capabilities.

• The Need for Specialized NHI Incident Response: The tj-actions/changed-files incident highlights the need for tailored incident response processes for NHIs. These should account for NHIs’ unique characteristics, including their diverse types and the potential impact of disrupting automated workflows.

Strengthening Your NHI Security Posture and Incident Response Capabilities

To mitigate risks and effectively respond to future incidents, organizations should implement the following:

• NHI inventory: Record the credentials and integrations used by CI workflows, their owners, permissions, and expiry dates. Cremit can surface exposures found in supported connected sources, but provider access records are needed to investigate actual use.

• Zero Trust for NHIs: Extend Zero Trust principles to all NHIs, ensuring continuous access validation.

• Least Privilege: Adhere to the principle of least privilege, granting NHIs only the necessary permissions.

• Continuous Monitoring and Threat Detection: Implement real-time monitoring and behavioral analytics for NHIs. StepSecurity Harden-Runner exemplifies this for GitHub Actions.

• Automated response: After confirming a compromised credential, revoke or rotate it at the issuing service and inspect its activity. Cremit helps detect exposures in supported connected sources, verify supported credential types, and assign findings. It does not automatically revoke identities or isolate suspicious activity.

• Secrets management: Store credentials in an appropriate vault, limit workflow permissions, and use short-lived credentials where the provider supports them. Rotate or revoke a compromised key at its issuing service.

• Incident response: Document how to identify affected workflows, revoke or rotate credentials, review provider logs, and restore trusted builds. An exposure finding can help locate a credential; determining its usage and blast radius requires investigation.

• Regular Security Assessments and Audits: Conduct security assessments of third-party integrations and review NHI permissions.

Conclusion: Proactive NHI Security and Strong Incident Response Are Essential

The compromise of the tj-actions/changed-files action serves as a potent reminder that NHIs are attractive targets for attackers. As organizations increasingly rely on automation and interconnected systems, securing these machine identities, paired with a strong incident response framework, must be a priority.

The tj-actions incident shows why CI credentials need owners, limited permissions, and a tested response procedure. Scan supported sources for exposed credentials, then use CI and cloud provider logs to investigate activity and contain the incident.

Related reading

• When the Security Scanner Became the Weapon, A Cyber Kill Chain Analysis of the Trivy Supply Chain Attack
• Clinejection: prompt injection and the unauthorized Cline CLI release
• Nx Package Supply Chain Attack: How a GitHub Actions Vulnerability Caused a Global Crisis