A compromise of the popular Microsoft-owned “GitHub Actions” tool turned into a massive supply chain attack, at this point thought to be responsible for the follow-on exposure of over 23,000 GitHub repositories.
The compromise took place on March 14 and the malicious code was removed by Microsoft the following day. A second possible compromise of other Actions surfaced in the early hours of March 18, but researchers do not yet see a connection to the original breach.
Supply chain attack on GitHub exposed secrets in repositories
GitHub Actions is used by developers to automate development workflows. The breach was detected by security firm StepSecurity on March 14, which estimates that it began sometime around the middle of the day by UTC time (and in the morning hours for most of the US). The firm quickly released a drop-in action to the public that fixed the issue, and Microsoft followed up with an official patch of the code on March 15. StepSecurity hosted an “office hour” on March 17 to assist with recovery, which is viewable on YouTube.
The primary impact of the supply chain attack is on GitHub repositories that contained secrets in their build logs. The malicious code was designed to comb through workflow logs that are publicly accessible, for example those stored in public repositories, but the researchers say there is no evidence of any secrets being exfiltrated to remote network destinations at this time. The attackers changed the Action’s code to update multiple version tags, which then began referencing the malicious commit.
The source of the breach appears to be a compromised Personal Access Token (PAT) linked to the “@tj-actions-bot” bot account used to maintain the repository, though there is not yet any information about who the attacker might be or exactly how they gained access. The compromised Action made use of a malicious Python script that dumped CI/CD secrets from the Runner Worker process. 23,000 GitHub repositories are potentially impacted, though actual compromise would depend on if secrets were available publicly as described. And in absence of evidence of mass exfiltration of data, it is unclear which (if any) repositories the unknown attackers were targeting.
Examples of secrets that could have potentially been exposed by the supply chain attack include user PATs, RSA and AWS keys, and NPM tokens. However, there are not yet any public reports of Github repositories being compromised in this way. Private repositories are unlikely to be impacted by the vulnerability.
A CVE has been assigned to the supply chain attack (CVE-2025-30066) with a severity score of 8.6. Though there is no known connection as of yet, a prior published vulnerability from January 2024 (CVE-2023-49291) also involved exploiting tj-actions and could have potentially been used to set up this attack.
More recent GitHub Actions vulnerabilities may also impact GitHub repositories
On March 18, StepSecurity updated their page covering the incident to indicate that several other GitHub Actions might be compromised to a point of representing a similar supply chain attack risk. These are associated with the code review tool “reviewdog” and appear to have been similarly compromised to steal secrets from GitHub repositories in the past, though the story is still developing as of this writing and there is not yet an indication that the tool is presently compromised. But the StepSecurity researchers advise that if the tool has been compromised this way in the past, it could very well happen again. There is also not yet any indication that these two incidents are directly related.
Attacks on code repositories have become increasingly popular over the past year or two. The Python Package Index, a Python platform popular with developers, has been very recently targeted with a spate of malicious packages that pose as assorted utilities that are affiliated with legitimate open source projects. The tainted packages contain malware that steals cloud tokens and other authentication secrets. North Korea’s state-backed Lazarus Group was also recently found to be tucking malicious code into the widely-used npm software repository. These bogus packages are also designed to steal authentication tokens and crypto wallet information, with some also adding a backdoor for continued access. As with the Python attacks, the North Korean hackers name the tainted packages similarly to a known legitimate package and hope that targets are not paying close attention to what they download.
Jason Soroko, Senior Fellow at Sectigo, expands on why Github repositories are such a point of interest for hackers (and what organizations can do about it): “GitHub’s CI/CD ecosystem is a high-value target for malicious code injections. The compromise of tj-actions/changed-files highlights how attackers can retroactively alter version tags to include a hidden payload that extracts and exposes sensitive secrets through build logs. The injected Python script, sourced from an unverified GitHub gist, manipulates trusted workflows to leak AWS keys, GitHub PATs, npm tokens, and private RSA keys. Even without confirmed evidence of active exfiltration, the incident (CVE-2025-30066, CVSS 8.6) exposes systemic vulnerabilities inherent in third-party dependencies and the automation pipeline. Organizations should strictly pin GitHub Actions dependencies to specific commit SHAs rather than mutable version tags to prevent retroactive malicious updates. Security professionals must audit their repositories for usage of the compromised Action and replace or remove it entirely, rotating all potentially exposed secrets including AWS keys, GitHub PATs, npm tokens, and RSA keys. Additionally, establishing allow-lists for approved Actions, employing OpenID Connect (OIDC) instead of static credentials, and continuously monitoring CI/CD environments for abnormal behaviors are best practices to proactively mitigate these kinds of supply chain attacks.”
Allon Mureinik, Sr. Software Engineering Manager at Black Duck, adds some insights about the possible methodology of the attack: “There are several interesting points about this attack that are worth considering. First, from the perspective of the action that was compromised- the original malicious commit that compromised this GitHub action was made to look as though the Renovate bot authored it, but it unlikely that the bot actually authored this malicious commit. It’s worth noting that this commit was unverified, and having a policy that requires all submissions to the repo be signed may have prevented this attack. Having said that, requiring contributors to sign their commits does add a bit of overhead, and may scare aware novice developers, so maintainers should consider this tradeoff between security and usability carefully before making such a decision. Second, from the perspective of anyone using this action – the SaaS nature of GitHub actions does not invalidate the basic security best-practices. The issue was detected by monitoring the network and detecting an anomalous endpoint that appeared in the workflow’s traffic. A GitHub Action is ultimately a piece of software, and like any piece of software, there are SCA solutions to ensure that the version you’re using is patched and up to date. While it may be tempting to shrug all these considerations off as “the platform’s problem”, the responsibility to ensure the security of a software project lies with those who build it, whether it’s built locally or by using a third-party service like GitHub.”
Dr. Katie Paxton-Fear, Principal Security Research Engineer at Harness, adds some considerations for potential victims and “lessons learned” for others: “Users of the “changed-files” action should immediately rotate their credentials. This involves invalidating existing credentials and generating new ones, effectively neutralizing any stolen information. This incident highlights the growing threat to open-source projects. Attackers are increasingly targeting these projects to distribute malware or steal credentials, leveraging their trusted status. Open-source maintainers must stay informed about evolving attack techniques and remain vigilant. While this attack doesn’t undermine the value of open source, it underscores the limited resources and security challenges faced by many projects. Organizations heavily reliant on open-source software should consider providing support to enhance the security posture of these vital projects. The takeaway for this attack is that the method they used to actually get the code passed the maintainers, so much so the maintainers actually didn’t attribute it correctly the first time. Because the attackers knew the bot is trusted, they managed to essentially use a dependency bot as a malware mule.”
