GhostAction GitHub Actions Attack Steals Secrets
The GhostAction GitHub Actions attack is back, and its payload now reads a repository’s entire git history. Researchers report that attackers took over two well-known maintainer accounts on October 8 and pushed a workflow called “Security Audit” into 345 repositories within minutes. Rotating your current Actions secrets no longer settles the exposure, because the workflow also collects credentials that were committed once and deleted years ago.
What Happened
StepSecurity describes the October 8 GhostAction GitHub Actions attack as two automated sweeps. Using the account of Takashi Kitao, author of the pyxel game engine, the attacker pushed the workflow to 27 repositories. Eight hours later the account of Henry Wu, original author of Uber’s athenadriver, was used to push it to 318 repositories in 16 minutes, including uber/athenadriver, where he kept write access. The commits went straight to the default branch under the owners’ own names, without a pull request. The likely entry point is a leaked personal access token from infostealer logs or credential dumps; that is the researchers’ inference, not a confirmed finding.
The workflow, named “Security Audit” or “Github Actions Security”, runs on every push to any branch and on manual trigger. It sends the repository’s named secrets to a hard-coded IP address (193.32.204[.]199) over plain HTTP. The new part is what it does with a full checkout: it searches the working tree and, through git log with the –all option, every commit on every branch for 13 credential patterns, including AWS keys, GitHub and GitLab tokens, and Anthropic, OpenAI and OpenRouter API keys. StepSecurity confirmed from the run log that the exfiltration from uber/athenadriver completed.
The scale is still unclear. Socket counts more than 500 GitHub accounts and tens of thousands of repositories since October 7. GitGuardian, looking at August 31 to September 30, counts 772 public repositories belonging to 373 users and organizations, with 2,577 secrets targeted. StepSecurity’s code search found 378 repositories with the workflow live on the default branch on October 9. As of the reports we read, no malicious package releases have been published with the stolen publishing credentials; StepSecurity notes that this is not evidence the credentials are safe.
Why It Matters
The remediation has changed. A secret that was committed in 2019 and deleted the next day is still in the history, and the workflow takes it. The attacker also moves in under legitimate identities, so audit logs look normal unless someone reads the workflow content. One control did stop the exfiltration in a repository StepSecurity analyzed: a requirement to approve workflow runs.
For DACH, we have no known German victims, and the reports name mostly open-source maintainers. Assessment: any mid-market company with developers who keep access tokens on laptops, mirror repositories or publish packages is exposed to the same chain. We covered a similar identity-based route into the build chain in our Keyv npm worm post and our AsyncAPI post.
What You Should Do Now
- Search your GitHub organization and personal repositories for the workflow names “Security Audit” and “Github Actions Security”, the file names security-audit.yml and github_actions_security.yml, and the address 193.32.204[.]199 in workflow files. StepSecurity says to treat any hit since August 31, 2026 as a confirmed breach.
- If you find one, rotate every credential that was ever committed to any branch, not only the configured Actions secrets: cloud keys, AI provider keys, registry and package tokens, GitHub and GitLab tokens.
- Revoke the GitHub credential that allowed the push, and delete the workflow from all branches, not just the default branch. Check forks too.
- Hold releases until the repository is clean, and review recent publications if publishing tokens were present.
- Turn on approval for workflow runs, protect the workflows directory with branch protection and required reviews, and restrict outbound traffic from runners to an allowlist.
DIESEC Perspective
The weak point is who can push to a default branch and where their tokens live, not GitHub’s code. Treat a developer’s personal access token as a production credential, with the same expiry and monitoring.
Not sure whether a workflow like this has run in your repositories? Contact DIESEC for a rapid review of your CI/CD configuration and a credential exposure check across your repository history.
Sources: StepSecurity | The Hacker News | GitGuardian | Socket
Published: 2026-10-13 | Category: Supply Chain Security | ~4 min read
