On Oct. 8, attackers running the GhostAction credential-theft campaign used two hijacked maintainer accounts to push the same fake “security audit” workflow into 345 GitHub repositories, according to StepSecurity. The sweeps took minutes, and the commits carried the victims’ own names.
What StepSecurity reports
StepSecurity’s analysis describes two automated windows. Starting at 13:20 UTC, the account of Takashi Kitao, author of the 18,400-star game engine pyxel, pushed the workflow to 27 repositories. Eight hours later, the account of Henry Wu, original author of the athenadriver project, pushed it to 318 repositories between 21:10 and 21:26 UTC. Of those 318, StepSecurity counts 39 source repositories and 279 forks.
The workflow is named “Security Audit” or “Github Actions Security” and is committed straight to the default branch. StepSecurity says the run log from the uber/athenadriver repository shows the attacker’s server acknowledging receipt four seconds after the workflow started, which it reads as confirmation that exfiltration completed.
GitGuardian, which named the campaign GhostAction in September 2025, added an update on Oct. 9 that cites Socket’s analysis of the same burst. It reports that, unlike the September wave when GitHub held most runs for approval, these runs executed and Socket confirmed successful exfiltration.
How the chain works
StepSecurity lays out four stages. The attacker first obtains a maintainer’s GitHub credential, which it calls “most plausibly” a personal access token from infostealer logs or credential dumps. The attacker then scans the repository’s workflow files for secret names, commits a workflow disguised as a security improvement under the victim’s identity, and lets the next push trigger it. The workflow sends the secrets to a hardcoded address, 193.32.204[.]199, over plain HTTP.
That is a pipeline with no exploit in it. Every step uses a feature working as designed: a valid token, a write permission and a workflow trigger. Rohan Prabhu of StepSecurity wrote in the analysis: “Nothing in an audit log looks anomalous unless the workflow content itself is inspected”. The commit message in the athenadriver case was simply “Add security audit workflow”, and StepSecurity notes the commit is unsigned.
What changed in October
The October payload goes after more than the secrets a repository has configured. StepSecurity says it checks out the full git history and searches both the working tree and the history for 13 credential patterns. Those cover AWS keys, GitHub and GitLab tokens, and API keys for Anthropic, OpenAI and OpenRouter. A credential that was committed years ago and deleted still sits in the history, so a repository with clean current settings can still leak it.
StepSecurity also says the workflow tags what it sends depending on whether reconnaissance found named secrets, which lets the operator sort incoming data by value without opening it.
The wider campaign
GitGuardian’s data puts the scale well above the October burst. Between Aug. 31 and Sept. 30, 2026, the malicious workflow reached 772 public repositories belonging to 373 users and organizations, targeting 2,577 secrets. The most common were SSH keys and deployment credentials (446), Azure credentials (218) and container registry credentials (142).
The first wave, in September 2025, hit 817 repositories belonging to 327 developers and exfiltrated at least 3,325 secrets, GitGuardian says. A year on, the technique is the same and only the destination server has changed. In the September 2026 wave, GitHub’s approval gate blunted much of the damage: of 3,669 workflow runs GitGuardian collected, 499 executed, and 336 completed successfully, exfiltrating 26 secrets from 13 repositories. The October runs did not stall that way, according to the Socket analysis GitGuardian cites.
Cleanup is slow. GitGuardian found that by Oct. 5 only 124 of the 772 repositories, 16 percent, had been cleaned in public history. In 92 cases the attacker edited a workflow left over from an earlier wave and pointed it at the new server. GitGuardian’s summary: “Our data shows that GhostAction never really stopped.”
It also found a second problem. Thirteen victim repositories were also used for cryptomining through GitHub Actions, in at least four separate campaigns. GitGuardian concludes the stolen GitHub credentials are probably not exclusive to one operator, because leaked tokens and infostealer logs circulate among many actors.
What it means for the security leader
The control gap here sits in identity. A maintainer account with write access to hundreds of repositories can publish code that every downstream user trusts, and nothing in the commit record marks it as hostile. Two earlier CyberTech pieces describe the same pattern: a GitHub Actions fix that undid itself over nine days, and a credential-stealing worm in an npm release. In each, the access that mattered was a token.
GitGuardian’s conclusion changes the incident response plan. Rotating the secrets the workflow took is not enough if the GitHub credential that allowed the injection stays valid, because someone else may already hold it.
What defenders should do this week
- Search every repository and fork you maintain for workflow files named security-audit.yml or github_actions_security.yml added since Aug. 31, 2026. StepSecurity advises treating any hit as a confirmed breach.
- Revoke the GitHub credential used for the commit first, then rotate every Actions secret and every credential found anywhere in the git history.
- Delete the workflow from all branches and check forks, which StepSecurity says carry the file and can trigger it on later pushes.
- Require pull requests and branch protection on default branches, and review audit logs for direct commits that add workflow files.
- Prefer fine-grained, short-lived tokens over classic personal access tokens for maintainers with wide write access.
