GitHub supply chain attack spills secrets from 23,000 projects
- Reference: 1742214849
- News link: https://www.theregister.co.uk/2025/03/17/supply_chain_attack_github/
- Source link:
StepSecurity disclosed a compromise of the popular GitHub Action tj-actions/changed-files, which works to detect file changes in open source projects, noting that more than 23,000 GitHub repositories currently use the automation project's code.
The security shop said attackers compromised the project at some unknown point before March 14 (March 12, according to Sysdig) and altered its code so the Action would leak secrets from a project's developer workflow into build logs.
[1]
In cases where these logs are publicly available, such as public repositories, it means that any project using tj-actions/changed-files would be leaking secrets for all to see. The risk to private repos is thought to be much lower, but maintainers should still consider their projects compromised.
[2]
[3]
The GitHub Action was tampered with to inject a Node.js function containing base64-encoded instructions to run a Python script that leaked a project's continuous integration / continuous delivery ( [4]CI/CD ) secrets from the Runner Worker process, according to [5]Sysdig .
Such secrets can include API keys, passwords, access tokens, and more, so it will come as some relief to admins that there is no evidence that any of the secrets leaked from public repos were exfiltrated to any outside server.
[6]
Similar malicious code could be found in another project – Flank – Sysdig noted, and in this case, the data was sent to a GitHub Gist via a POST request.
The motivation for the attack, like the identity of those behind it, is unknown but the tj-actions team confirmed that the compromise unfolded after a bot account was breached.
"This attack appears to have been conducted from a PAT [personal access token] linked to @tj-actions-bot account to which 'GitHub is not able to determine how this PAT was compromised,'" [7]said software engineer Tonye Jack, author of tj-actions.
[8]
Jack later confirmed that the password for the bot account was updated, [9]passkeys are now used to secure the account, its permissions were downgraded to the minimum necessary, and commits must now be signed to ensure the integrity of contributions.
"The personal access token affected was stored as a GitHub action secret which has since been revoked," he added. "Going forward no PAT would be used for all projects in the tj-actions organization to prevent any risk of reoccurrence.
"We'll continue to monitor and enhance security measures as needed to prevent any future incidents. If you have any additional recommendations, feel free to share them."
Cybersecurity experts covering the attack have all advised that an immediate response is required from project maintainers to ensure their secrets aren't exposed. The researchers over at Wiz [10]said they've identified "dozens" of public repos with exposed secrets freely available for anyone to see, including those owned by large organizations.
[11]Microsoft admits GitHub hosted malware that infected almost a million devices
[12]200-plus impressively convincing GitHub repos are serving up malware
[13]GitHub's boast that Copilot produces high-quality code challenged
[14]Python dethrones JavaScript as the most-used language on GitHub
"Some of the leaked secrets we've identified so far include valid AWS access keys, GitHub Personal Access Tokens (PATs), [15]npm tokens , private RSA Keys, and more," said the Wiz team.
Project maintainers who think they might be affected are advised to audit their repos and rotate all secrets in any that use tj-actions/changed-files. These secrets should be considered compromised, and now that the attack is publicized, criminals will be scouring GitHub for useful data.
Both Wiz and Sysdig recommended that developers find alternatives for tj-actions/changed-files and remove all references to the GitHub Action across all repo branches.
GitHub generally suggests projects that use [16]Actions should pin them to specific commit hashes instead of version tags if they want to avoid similar supply chain attacks in the future.
"Pinning an action to a full-length commit SHA is currently the only way to use an action as an immutable release," its [17]guidance says . "Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. When selecting a SHA, you should verify it is from the action's repository and not a repository fork."
The compromise at tj-actions/changed-files has now been assigned a vulnerability: CVE-2025-30066 (8.6 – high).
The Register contacted Tonye Jack for additional information. ®
Get our [18]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z9hVMh54Ytz0ztFCF7VnBwAAABE&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z9hVMh54Ytz0ztFCF7VnBwAAABE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z9hVMh54Ytz0ztFCF7VnBwAAABE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://www.theregister.com/2023/03/02/cicd_supply_chain_security/
[5] https://sysdig.com/blog/detecting-and-mitigating-the-tj-actions-changed-files-supply-chain-attack-cve-2025-30066/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z9hVMh54Ytz0ztFCF7VnBwAAABE&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://github.com/tj-actions/changed-files/issues/2464#issuecomment-2727020537
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/cybercrime&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z9hVMh54Ytz0ztFCF7VnBwAAABE&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[9] https://www.theregister.com/2024/11/17/passkeys_passwords/
[10] https://www.wiz.io/blog/github-action-tj-actions-changed-files-supply-chain-attack-cve-2025-30066
[11] https://www.theregister.com/2025/03/10/infosec_in_brief/
[12] https://www.theregister.com/2025/02/26/infosec_bytes/
[13] https://www.theregister.com/2024/12/03/github_copilot_code_quality_claims/
[14] https://www.theregister.com/2024/11/05/python_dethrones_javascript_github/
[15] https://www.theregister.com/2024/11/05/typosquatting_npm_campaign/
[16] https://www.theregister.com/2021/10/28/github_actions_universe/
[17] https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions
[18] https://whitepapers.theregister.com/
Put M$ in charge of your CI . . .
. . . and see what happens ;)
People never learn.
Re: Put M$ in charge of your CI . . .
"The only thing we learn from history is that we do not learn from history."
-Georg Hegel 1820-something (series of lectures)
LOL, and who owns Github?
Rhetorical question.
Horses for courses.
Rather, put some people you've never met and have no contract with or support from in charge of your CI. At least large orgs would be protected if they dealt directly with people, but nowadays it's common to use whatever off the shelf solution exists without properly vetting it.
Something, something, world, oyster, pearl, dark hole, stinky fingers, no pearl.
Shocked Pikachu faces.
Well beyond my competence, but....
Do I detect the creak of stable doors being being closed while horses vanish off into the distance?
Re: Well beyond my competence, but....
Yes, but this is to remind users to check their repos for keys and such that their predecessor and/or coworkers should never have uploaded. If you don't think they're doing the same thing because they don't trust you, you're deluding yourself.
The "delete this action and find an alternative" seems kind of dumb advice. The vulnerability has been found, fixed, dodgy commits cleaned up and steps have been taken to prevent it happening again. Arguably this repository/organization is now more secure and has a better security posture than before. By switching surely you're now potentially swapping to an action written by someone else that's less maintained?
I am using this action in a couple of places, but went through the pain of pinning all actions to the commit SHA so I feel slightly vindicated now.