Hackers hijacked 1,900 GitHub accounts. Then they went after 30,000 repos.
The New Stack Amanda Caswell
Hackers took over about 1,900 GitHub accounts and pushed bad workflows into more than 30,000 repos. They went after CI secrets, cloud keys, and AI API tokens, and GitHub had to block the jobs.
Based on reporting by The New Stack, Amanda Caswell — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
Hackers didn’t need a GitHub bug for this one. They used stolen developer credentials to edit workflows directly, then turned roughly 1,900 accounts into a delivery system for credential theft across more than 30,000 repositories. The targets were the usual juicy bits: CI/CD secrets, cloud access keys, and API keys from AI providers.
GitGuardian says the GhostAction campaign ramped up on October 8 and 9, when the attackers reached repositories tied to about 3,000 users and organizations and tried to pull out 3,174 secrets. The trick was almost boring in its simplicity: add a workflow that looks like routine security plumbing, give it a name like security-audit.yml or github_actions_security.yml, and wait for it to run with access to secrets that legitimate builds already use.
The attackers also went hunting through the full Git history, not just the live code. In the October variant, they used actions/checkout@v4 with fetch-depth: 0 to scan for AWS keys, GitHub and GitLab personal access tokens, Google and Firebase keys, and API tokens from Anthropic, OpenAI, and OpenRouter. Later versions even grabbed nearby lines so they could pair AWS key IDs with the matching secret access keys. The stolen material was sent to 193.32.204.199 over HTTP.
GitHub did block the malicious workflows, but the campaign still got traction. GitGuardian says the payload was deployed in phases: an initial push to about 160 previously targeted victims, then about 20 minutes later a much larger blast into 28,000 new repositories. The company hasn’t pinned down how many credentials actually made it out, only that some exfiltration happened.
The August and September wave was smaller but still ugly. GitGuardian found malicious workflows in 772 public repositories across 373 users and organizations. Of 3,669 recorded workflow runs across 605 repositories, only 499 actually executed, and 336 of those succeeded, exfiltrating 26 secrets from 13 repositories. GitHub’s approval controls stopped a lot, but the attackers reused 92 older workflows left behind from earlier compromises, including infrastructure that had been active since September 2025. By October 5, only 124 of the 772 affected repositories had been cleaned up.
My take — AI-written commentary, not fact-checked reporting
This is why workflow files deserve the same paranoia as production code, because attackers clearly already treat them that way. Reusing old poison in fresh repos is the sort of grimly efficient move that keeps open platforms honest — and keeps the cleanup teams busy. GitHub blocking the run is good; leaving 84% of affected repos dirty for days is the part that should sting.
Read more about this at: The New Stack