A new wave of the GhostAction campaign is planting fake “security audit” workflows in GitHub repositories, and this time it harvests credentials from the entire git history, not just the CI secrets store. For defenders, rotating Actions secrets no longer settles the matter: anything ever committed to an affected repository now has to be treated as stolen.
What happened
On 8 October 2026, attackers behind GhostAction, a GitHub Actions credential-theft operation first exposed in September 2025, took over two well-known open-source maintainer accounts and pushed a malicious workflow to roughly 345 repositories in two bursts lasting minutes. According to StepSecurity, the account of Takashi Kitao, who wrote the popular pyxel game engine, was used to seed 27 repositories from 13:20 UTC. Henry Wu’s account (henrywoo), which belongs to the original author of Uber’s athenadriver, followed roughly eight hours on, landing the file in 318 repositories between 21:10 and 21:26 UTC.
Because henrywoo kept write access to the Uber-owned athenadriver repository, the workflow landed on its default branch with no pull request or review. StepSecurity says the run log for that repository shows the exfiltration succeeded, with the attacker’s server acknowledging receipt four seconds after the job began.
Those two accounts are only the visible tip. Socket reported on 9 October that more than 500 GitHub accounts had pushed the rogue file into tens of thousands of repositories from 7 October onwards, including organisation-owned ones reached via compromised contributors. The Hacker News, citing GitGuardian, adds that an earlier phase between 31 August and 30 September touched 772 public repositories. No malicious package releases have been seen yet, but the stolen registry tokens remain dangerous until revoked.
The technical picture
The chain is simple and effective. The attacker starts with a working maintainer credential, which StepSecurity and The Hacker News both suggest is probably a personal access token harvested by infostealer malware or circulating in leaked collections. The repository’s existing workflows are then read to learn the names of its configured secrets, and those names are written into a new workflow file before it is committed under the victim’s own identity.
The file is named either security-audit.yml (“Security Audit”) or github_actions_security.yml (“Github Actions Security”), with bland commit messages such as “Add security audit workflow”. It runs whenever anything is pushed, whatever the branch or tag, and can also be launched by hand, so the injection commit itself sets it off.
What has changed in this wave is reach. Earlier GhostAction payloads only sent the named Actions secrets. The October version also checks out the full repository history and scans both the working tree and every past commit for 13 credential types: AWS keys and temporary session tokens; API keys for Anthropic, OpenAI and OpenRouter; GitHub and GitLab tokens; Google and Firebase keys; plus Slack and SendGrid credentials. It also grabs the lines around any AWS key ID so that IDs can be matched to their secret keys. Everything goes out in a single unencrypted HTTP POST to a fixed IP address, 193.32.204[.]199. A query-string tag (c=monami or c=new) signals whether named secrets were captured.
Two details matter for responders. First, there is no DNS lookup, so domain reputation and DNS filtering will not see the exfiltration. Second, StepSecurity observed the attacker returning to pyxel and manually re-running the workflow twice, which points to an operator actively at the keyboard rather than pure automation.
Why it matters for UK organisations
Many UK software teams, across fintech, retail, the public sector and its suppliers, depend on GitHub Actions. Many also rely on open-source maintainers who keep long-lived write access to organisation repositories, exactly the trust path that carried this payload into Uber’s codebase. If any of your contributors has had a token stolen, your repositories are within reach.
The history sweep is the sharpest problem. Most mature teams have at some point committed a key, spotted it, deleted it and moved on. That deleted key is still in the history, and this payload goes looking for it. Private repositories, forks and internal mirrors are most exposed, because that is where credentials tend to be committed. For a regulated UK organisation, stolen cloud keys can quickly become a reportable personal data breach or an operational incident.
The campaign also feeds the wider supply chain. Stolen PyPI, crates.io or container registry tokens let an attacker publish as a trusted maintainer, which turns one compromised developer into a downstream problem for everyone who installs that package.
Expert view
What strikes me about this wave is how little looks wrong in the audit trail. The commits come from real accounts, carry plausible messages and name themselves after security tooling. Login-anomaly alerting sees nothing, because the token is valid. Detection has to look at what changed, not who changed it.
In my experience, CI/CD platforms are among the most over-trusted parts of an estate. Runners get broad outbound access, workflow files are rarely protected the way application code is, and personal access tokens outlive the projects they were created for. GhostAction exploits all three at once.
The most useful lesson comes from a repository where the attack failed. StepSecurity reports that in typecho-fans/plugins the attacker’s attempts to re-trigger the workflow stalled because the project requires approval before workflow runs. That one setting broke the chain. When we assess pipelines, that control is often absent, despite costing nothing.
What to do now
- Hunt first. Search your organisation’s code for the workflow file names, the AKIA_CTX_START marker, the c=monami tag and the IP 193.32.204[.]199. Check every branch and fork, not just default branches, because code search does not index forks.
- Check egress and audit logs. Search firewall, proxy and self-hosted runner logs for connections to 193.32.204[.]199 since early September 2026, and block it. In the GitHub audit log, look for workflow files added directly to default branches, manual dispatches of new “audit” workflows, and bursts of unsigned commits across many repositories.
- Treat any completed run as confirmed theft. StepSecurity advises reviewing runs back to 31 August 2026. A successful run means every named secret and every credential in the history was sent.
- Rotate broadly. Replace every Actions secret, plus any credential that has ever appeared in the repository, including keys deleted years ago. For AWS keys, review CloudTrail for new IAM users, new access keys and activity in unusual regions.
- Close the entry point. Revoke the compromised account’s tokens, sessions, OAuth grants and SSH keys, and re-enrol it with phishing-resistant MFA. Remove the workflow from all branches and revert the commits. Hold releases until clean if publishing tokens were exposed.
- Harden for next time. Require approval for workflow runs, protect .github/workflows with branch protection and mandatory review, enable secret scanning with push protection, prefer short-lived tokens over long-lived PATs, and restrict runner egress to an allowlist. These map neatly to the Cyber Essentials controls on secure configuration, user access control and firewalls.
Bottom line
GhostAction has gone from stealing a CI secrets list to mining a repository’s whole past. Hunt for the indicators today, rotate anything that has ever touched an affected repository, and turn on workflow approval gates. Then review who still has write access to your code.
Sources
- StepSecurity: GhostAction Returns: Malicious “Security Audit” Workflows Now Mine Credentials from Entire Git Histories
- Socket: New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials
- The Hacker News: Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories
