The short answer
A new GhostAction wave turns a compromised maintainer account into a mass secret-harvesting tool. The attacker pushes a workflow file named security-audit.yml (or a similar name) to every repository the account can write to. When it runs, it sends the repository’s Actions secrets and any cloud, AI or SaaS keys found anywhere in the git history to a hard-coded IP address over plain HTTP.
For any team that runs builds and releases through GitHub Actions, the lesson is simple. A secret that was ever committed, even years ago and later deleted, should be treated as exposed if a workflow like this could have run. Rotate first, then clean up the history.
What happened on October 8?
According to StepSecurity, the attacker first used the account of Takashi Kitao to push the malicious workflow to 27 repositories. About eight hours later the account of Henry Wu was used to push the same file to 318 repositories, most of them forks, in a 16-minute window. Both bursts were automated: one commit per repository, adding or updating a single workflow file with an innocent-looking name.
Socket, which analyzed the same wave independently, counted 346 affected repositories and listed uber/athenadriver and kitao/pyxel among them. It reported that the file was still on the default branch of several repositories it checked on October 9. At the time of writing Socket had seen no malicious package versions published to PyPI or crates.io as a result, but the stolen tokens would allow exactly that. The Hacker News, citing Socket, put the total at more than 500 compromised accounts and tens of thousands of repositories since October 7.
What does the malicious workflow steal?
Earlier GhostAction waves collected the named secrets that a repository’s own workflows reference, such as PyPI, npm and Docker Hub publishing tokens. GitGuardian counted 3,325 secrets stolen that way in the original 2025 campaign. The new version keeps that and adds a second step: it checks out the repository with fetch-depth: 0, runs git log -p --all and searches the complete history with regular expressions.
The patterns cover AWS access keys (including temporary STS keys), Anthropic, OpenAI and OpenRouter API keys, GitHub and GitLab personal access tokens, Google, Firebase and GCP keys, and Slack and SendGrid credentials. That means a key committed by mistake in 2022 and removed in the next commit is still in scope. The results are posted in cleartext, which also means anyone watching the network path could read them.
What it means for US & EU software teams
First, the pipeline is the target, not the code. The attacker does not need a vulnerability in your application. A single maintainer token with write access is enough to run code inside your CI with your secrets. Teams that review every application pull request but let workflow files change without review have their strongest controls in the wrong place. The rules for .github/workflows should be at least as strict as the rules for production configuration in your cloud and DevOps setup.
Second, AI API keys are now high-value loot. The workflow searches for Anthropic, OpenAI and OpenRouter keys alongside cloud credentials. A leaked model key is a direct bill and, for teams sending customer data to models, a data-access risk. Keep these keys in a secret manager with spend limits and per-environment keys, not in .env files that end up in commits.
Third, regulators treat this as an incident, not housekeeping. If a stolen cloud key could reach personal data, GDPR breach-notification timelines may apply, and NIS2, DORA and SOC 2 all expect documented secret rotation and access review. A dated record of which repositories were checked, which runs executed and which keys were rotated is what an auditor will ask for.
What should you do now?
- Hunt for the files. Search your organization for
security-audit.yml,github_actions_security.yml,security-check.ymland the IP 193.32.204.199 in workflow files, including forks and archived repositories. - Check the run logs. Look for Actions runs since October 7 that you did not start. If the workflow ran, assume every secret it could read is gone.
- Rotate, then clean. Rotate exposed Actions secrets and any key that ever appeared in git history. Rewriting history does not undo a theft that already happened.
- Lock down workflow changes. Require review from code owners for
.github/workflows, protect default branches, and limit which accounts and tokens can push. - Shrink what a job can steal. Use OIDC short-lived cloud credentials instead of long-lived keys, scope secrets to environments, and set the default
GITHUB_TOKENto read-only.
Frequently asked questions
What is the GhostAction campaign?
GhostAction is a supply chain attack on GitHub Actions that first appeared in September 2025. Attackers use compromised developer accounts to add a workflow file that sends repository secrets to an attacker-controlled server. A new wave on October 8, 2026 used the accounts of the pyxel author and the original author of Uber’s athenadriver to hit about 345 repositories.
How do I know if my repository was affected?
Search your repositories, including forks, for workflow files named security-audit.yml, github_actions_security.yml or security-check.yml and for the IP address 193.32.204.199. Then review GitHub Actions run logs since October 7, 2026 for runs you did not start. A run of the malicious workflow means its secrets should be treated as stolen.
Is deleting a leaked key from the code enough?
No. The new variant reads the complete git history with git log -p --all, so a key that was committed and later deleted can still be found. Rotate the key at the provider first, then remove it from history if needed.
Which credentials does the workflow look for?
It collects the GitHub Actions secrets used by the repository’s workflows and searches the code and history for AWS keys, Anthropic, OpenAI and OpenRouter API keys, GitHub and GitLab tokens, Google, Firebase and GCP keys, and Slack and SendGrid credentials.
How can teams prevent similar attacks?
Require code-owner review for changes under .github/workflows, protect default branches, enforce strong authentication on maintainer accounts, set the default GITHUB_TOKEN to read-only, scope secrets to environments and replace long-lived cloud keys with short-lived OIDC credentials.
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
GitGuardian — The GhostAction Campaign: 3,325 Secrets Stolen Through Compromised GitHub Workflows