- StepSecurity reports GhostAction attackers used two hijacked maintainer accounts to push a fake security workflow to 345 repositories on October 8, 2026.
- The workflow reads the full git history, so credentials deleted long ago are exposed. Rotating current Actions secrets is not enough.
- Require approval for workflow runs, protect the workflows folder, restrict outbound traffic, and rotate every credential ever committed.
Deleting a password from a code repository feels like fixing the leak. A new wave of the GhostAction campaign shows it does not. This attack reads the full history of a repository, not just today's files.
StepSecurity, a software supply chain security firm, says attackers hijacked two well-known open-source maintainer accounts on October 8, 2026. In two automated bursts lasting minutes, they placed the same workflow in 345 repositories.
What happened
The attacker first used the login of Takashi Kitao, creator of the pyxel game engine, which has 18,400 stars. Starting at 13:20 UTC, 27 repositories received the fake file through his account.
About eight hours later, the attacker used a second login, belonging to Henry Wu. In just 16 minutes, 318 repositories received the same file.
Wu wrote Uber's athenadriver. StepSecurity says he still had write access to the Uber repository. The file went straight to the master branch, with no pull request and no review.
The commit carried his real identity and was unsigned. Its message read "Add security audit workflow." StepSecurity says nothing in an audit log looks odd unless someone reads the workflow itself.
How the theft works
GitHub Actions is the system that builds and ships code. A workflow is a script that runs when something happens, such as a code push. The attacker's script is called "Security Audit". It runs on a push to any branch or tag, and it can also be started by hand.
First, it copies the repository's named secrets. The attacker learned those names earlier by scanning the workflow files. Next, it downloads the full repository with every branch and tag. A setting called fetch-depth: 0 does this.
That setting, plus the next command, is the upgrade. The script runs git log -p --all, a command that prints every change ever made on every branch. It searches the output for thirteen kinds of credential.
The list includes AWS keys and API keys for Anthropic, OpenAI and OpenRouter. It also covers GitHub, GitLab and Slack tokens, and SendGrid keys.
The history keeps old keys, even after someone deletes them. A key that sat in the code for one day in 2019 is found as easily as one in use today.
For AWS, the script also copies two lines on each side of a key ID. That lets the attacker pair the ID with its secret key.
All of it goes by plain HTTP to a raw IP address, 193.32.204.199. No domain lookup happens. Defenses that watch domain lookups see nothing.
Proof, limits and what is still open
The run log for uber/athenadriver shows the theft worked. The attacker's server sent back a reply four seconds after the job started.
In the athenadriver run, the workflow's token could only read contents. It could not push code by itself. The harm comes from what it steals.
The attacker targeted pyxel's publishing credentials for PyPI and crates.io. In the wrong hands, those could ship a tainted version of a popular library.
StepSecurity found no malicious releases so far. It says that does not prove the credentials are safe. They stay exposed until someone rotates them.
StepSecurity calls the count approximate, because victims clean up daily. It leaves out forks.
Socket, quoted by The Hacker News, says 279 forks under Wu's account carry the file. Socket also says more than 500 accounts have committed the workflow since October 7.
The Hacker News adds that GitGuardian tracked the same campaign earlier. From August 31 to September 30, it counted 772 public repositories owned by 373 users and organizations.
The lesson: history is part of the attack surface
Most security programs treat a leaked key as a single moment. You find it, remove it, rotate it and move on. This campaign treats a repository as an archive that keeps everything.
Think of tearing a page out of a book when every reader already holds a copy. The git history is those copies.
Each old mistake becomes a new target the day an attacker gets write access. The same attack also shows how much trust rests on people. One maintainer's access to one company repository was enough. The attacker needed only a compromised maintainer account.
How the two accounts were taken has not been confirmed. StepSecurity's description of the attack chain calls a leaked personal access token the most plausible route.
The one control that held
StepSecurity describes typecho-fans/plugins, a repository infected since September 5. On October 7, the attacker pushed an empty commit and a small README edit. The aim was to fire the workflow again.
Both runs stalled, because the repository requires approval for workflow runs. StepSecurity calls that approval gate the one control it saw stop theft this week.
Questions for your team
Ask who can push to your default branches without review. Include former contributors. Ask whether workflow runs need approval. Ask whether the .github/workflows folder has branch protection.
Ask whether build runners can reach only an approved list of destinations. A raw IP address over plain HTTP should fail that test.
Search your organization for a workflow named "Security Audit" or "Github Actions Security" since August 31, 2026. StepSecurity says to treat any hit as a confirmed breach.
Then rotate every credential ever committed, including AI provider keys. Revoke the compromised GitHub credential too. Delete the workflow from all branches, and check your forks, because the file travels with them.
A secret you deleted is still a secret you leaked. The history keeps it until you rotate it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: StepSecurity.
