If you maintain anything on GitHub, set aside ten minutes this week to search your organisation for a file called security-audit.yml. The reason is a credential-stealing campaign that has been quietly seeding that filename into repositories since the end of August, and which got noticeably louder on 8 October. It goes by GhostAction, a name The Hacker News carried over from the September 2025 incident that hit 817 repositories and 3,325 secrets. Same trick, new batch.
What the workflow does
The disguise is a good one: a workflow that claims to be a security scan, committed straight to the default branch under the maintainer's own name, with commit messages like "Add security audit workflow". StepSecurity's write-up shows the October variant triggering on a manual dispatch or on a push to any branch or tag. It checks out the full history, greps the working tree for thirteen kinds of credential, then runs git log -p --all to dig through everything that was ever committed. A key someone deleted in 2022 is still found. The haul, along with any named Actions secrets, goes in a single plain-HTTP POST to a hard-coded IP address, with no DNS lookup to give it away.
One detail worth sitting with: the workflow runs with a read-only GITHUB_TOKEN, so it cannot push code or publish a release itself. It does not need to. The prize is whatever it finds, such as AWS keys, GitHub and GitLab tokens, package registry credentials and, increasingly, API keys for AI providers.
How big it is, and what we do not know
Numbers differ by source and are moving. StepSecurity records one maintainer account (pyxel's author, a project with around 18,400 stars) used to push the workflow to 27 repositories on 8 October, and a second account used about eight hours later to push it to 318 in sixteen minutes, 279 of which were forks. The Hacker News reports Socket counting more than 500 accounts and tens of thousands of repositories carrying the workflow since 7 October. StepSecurity's own code search on 9 October found 378 repositories with a live copy on the default branch. Those figures describe different things (accounts, pushes, live files), so treat none of them as a final tally. Neither source reports a malicious package release built from stolen publishing credentials so far. That is a statement about today, not a promise.
At least one run was stopped by a setting rather than by skill: in typecho-fans/plugins the workflow stalled in action_required because the repository demanded approval before running workflows. Free protection, when you have it switched on.
A short list for Monday
- Search code in your organisation for
security-audit.yml,github_actions_security.ymlandsecurity-check.ymlunder.github/workflows, and for the exfiltration address StepSecurity publishes. - If a copy has run, treat every secret reachable from that repository as stolen, including anything ever committed to history, and rotate it. Revoke the maintainer credential too, or the injection simply happens again.
- Look at forks, private ones included. They inherit the file and, as Socket points out, are where committed credentials tend to live.
- Require pull-request review for changes under
.github/workflows, and require approval for workflow runs where the repository can live with it. - Restrict runner egress. A build job has little reason to POST to a bare IP address on port 80.
- Ask where your developers' personal access tokens come from and how long they live. The likely entry here is a token lifted from an infostealer log.
The lesson is old and still unlearned in many pipelines: the CI system holds the keys to everything, and anyone who can edit its configuration can read them. If you want help auditing workflow permissions and secrets across a large estate, write to sales@halfteck.com.