Fake "Security Audit" GitHub workflows now sweep git histories for keys

Fake "Security Audit" GitHub workflows now sweep git histories for keys

9 October 2026: Attackers are using stolen GitHub maintainer credentials to commit a workflow named "Security Audit" that sends a repository's Actions secrets, and every credential ever committed to any branch, to a server at 193.32.204.199. Security firms StepSecurity and Socket both tie it to GhostAction, the campaign that took more than 3,000 secrets from 817 repositories in September 2025, and both say a single completed run of the workflow should be treated as a successful theft.

Not yet independently verified. The figure of more than 500 accounts and tens of thousands of repositories is Socket's own update and has not been counted by anyone else; StepSecurity's count on the same day was 378 repositories with a live workflow, forks excluded. GitHub has not commented in either report. We will update this when it can be confirmed, and remove this note.

Two maintainer accounts, 345 repositories in one day

On 8 October the account of Takashi Kitao, author of the Pyxel game engine, pushed the workflow to 27 repositories between 13:20 and 13:44 UTC. That evening, between 21:10 and 21:26 UTC, the account of Henry Wu pushed it to 318 repositories, 39 of his own projects and 279 forks, ending with uber/athenadriver, an Uber-owned repository where he keeps write access as its original author. StepSecurity found the run log there: the attacker's server acknowledged the upload four seconds after the run started.

Socket's update the next day says it has now found more than 500 GitHub accounts that committed the same workflow to tens of thousands of repositories since 7 October, some of them organisation-owned repositories reached through a compromised contributor. StepSecurity counted 378 repositories with the workflow still live on the default branch on 9 October, forks excluded.

What the workflow takes, and why rotating secrets is not enough

The file arrives as .github/workflows/security-audit.yml or github_actions_security.yml, with commit messages such as "Add security audit workflow". It runs on any push to any branch or tag and on manual dispatch, checks out the full history, and does four things: it sends the Actions secrets an earlier reconnaissance step found, searches the working tree for 13 credential patterns, runs the same search over git log for the whole history, and keeps the lines around each AWS key ID so a key pair can be rebuilt.

The patterns cover AWS access keys and session tokens, Anthropic, OpenAI and OpenRouter API keys, GitHub and GitLab personal access tokens, Google and Firebase keys, Slack tokens and SendGrid keys. The history sweep is new in this wave, and it means a key deleted from a repository years ago is still taken if it was ever committed. For Pyxel the named secrets included its PyPI and crates.io publishing credentials. Neither firm had seen a malicious package release as of 9 October.

StepSecurity's point is blunt: rotating repository secrets does nothing while the stolen maintainer credential that injected the workflow still works.

Checking a repository and its forks

Both reports give the same order of work: search every repository the affected account can write to for those two workflow files since 31 August, revoke the account's sessions, tokens, OAuth grants and SSH keys rather than only rotating them, rotate every credential ever committed, delete the workflow from all branches, and look for outbound connections to 193.32.204.199, including from self-hosted runners. Socket adds that forks from the affected namespaces carry the file, so Actions should stay off on such a fork until it has been checked, and that AWS keys found in history call for a CloudTrail review of the exposure window.

Requiring approval before workflows run stopped one attempt: on 7 October an injected workflow in typecho-fans/plugins was held because the repository required approval for runs.

Our continuous integration category lists 12 products and our DevOps category 15.

Related on TrustList:

• Google Cloud's legacy Monitoring and Logging agents reached end of support on 28 September 2026: migrate to the Ops Agent

Sources

• StepSecurity: GhostAction Returns: Malicious "Security Audit" Workflows Now Mine Credentials from Entire Git Histories, 9 October 2026
• Socket: New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials, 9 October 2026
• The Hacker News: Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories, 10 October 2026