How to Check Your Repos for the GhostAction Workflow and Lock Down Actions
A fake security-audit workflow is stealing secrets from GitHub repositories. Here are the searches, the cleanup order, and the settings that stop it.
On this page 8 sections
To check for GhostAction, search your repositories for workflow files named security-audit.yml, github_actions_security.yml, or security-check.yml, and for the markers AKIA_CTX_START and 193.32.204.199. If you find one, assume every secret in that repository, including deleted ones, is exposed and rotate it.
GhostAction is a supply chain campaign that plants a fake "security audit" workflow in a repository using a stolen maintainer credential. The workflow then ships the repository's secrets to an attacker's server. StepSecurity reported a new wave on October 8, 2026, and The Hacker News covered it on October 9 and updated the story on October 15. This guide is for maintainers and platform engineers who own GitHub Actions. It gives you a search checklist, a log review, a cleanup order, and five settings that would have blunted the attack. Backtrace covers developer security and DevOps, and we focus on steps you can run today.
What is the GhostAction campaign?
GhostAction first appeared in September 2025, when StepSecurity reported over 3,000 secrets stolen from 817 repositories. A second wave surfaced in October 2026. On October 8, two maintainer accounts were used to push malicious workflows to 345 repositories in two automated windows: 27 repositories from one account, and 318 from another in a 16-minute span. Socket later reported that more than 500 GitHub accounts had committed the workflow to tens of thousands of repositories since October 7.
The attacker most likely holds a maintainer's GitHub credentials, probably a personal access token from infostealer logs or a credential dump. With that access, the attacker scans workflow files for secret names, then pushes a workflow that looks like routine hygiene. The workflow triggers on workflow_dispatch and on unfiltered pushes, so it fires quickly. Read StepSecurity's GhostAction Returns analysis for the full indicator list.
What does the malicious workflow do?
The workflow checks out the repository with full history, so fetch-depth: 0. A single "Audit" step then appends the repository's named secrets, scans the working tree for 13 credential patterns, and scans the entire git history for the same patterns. That means a key you committed and deleted years ago is still exposed. It also pairs AWS access key IDs with their secret keys by reading surrounding context.
Targets include AWS, Anthropic, OpenAI, and OpenRouter API keys, GitHub and GitLab tokens, SSH keys, Azure, DockerHub, and GHCR credentials, database and FTP logins, Google Cloud and Firebase keys, chat bot tokens, and Cloudflare, npm, and PyPI credentials. The data goes out through a curl call to 193.32.204.199 over plain HTTP. Because the destination is a raw IP, there is no DNS lookup for a domain-based filter to catch. The Hacker News report summarizes the mechanics.
How do you check whether you are affected?
Work through these steps in order. Each one narrows the question from "do I have the file" to "did it run."
- Search GitHub code for
"AKIA_CTX_START" path:.github/workflows, for"c=monami", and for"193.32.204.199" path:.github/workflows. Repeat each query withorg:your-orgto cover your organization. - List workflow files in every repository and look for
security-audit.yml,github_actions_security.yml, andsecurity-check.yml. Also check forks, since forks of infected repositories carry the file. - Review your audit log for maintainer commits that add workflow files directly to default branches without a pull request. Commit messages seen in the campaign include "Add security audit workflow" and "Trigger security scan."
- Look for
workflow_dispatchruns of a newly created audit workflow, and for rapid, unsigned commits across many repositories within minutes. - Check runner and proxy egress logs for connections to
193.32.204.199on ports 80 and 3000. If you use Harden-Runner, review its telemetry from early September 2026 forward.
Treat any completed run named "Security Audit" or "Github Actions Security" as confirmed exfiltration. StepSecurity confirmed one case in a run log where the attacker's server acknowledged receipt four seconds after the workflow started. A repository with the file but no completed run is lucky, but it is still compromised in the sense that the credential that pushed the file is out there.
What is new in the October wave?
Four changes make the October wave harder on defenders than the 2025 version. First, it harvests full git history with git log -p --all, so old mistakes count. Second, it pairs AWS key IDs with secret keys by capturing surrounding context. Third, it adds AI-provider keys to its target list. Fourth, it sends data to a raw IP over plain HTTP, which avoids domain-based controls.
StepSecurity's count as of October 9 gives a sense of scale. It found 378 repositories with a live malicious workflow on the default branch, 182 with the history-mining marker, and 88 with the marker showing named secrets were sent. Those are a floor, not a ceiling, since the count covers only public repositories the researchers could see. GitGuardian separately tracked an earlier wave between August 31 and September 30, 2026, covering 772 public repositories and 2,577 targeted secrets.
One more detail helps with triage. The compromised accounts were used for injection, not owned by the attacker. If you see a commit from a trusted maintainer that adds a workflow file nobody discussed, the account holder is a victim, and the first call should be to them, not to a block list.
What is the right cleanup order?
Order matters, because rotating secrets while the attacker still holds a valid token only restarts the clock. Follow this sequence.
- Revoke the compromised GitHub credential, which is usually a personal access token or session, so the attacker cannot push again.
- Delete the malicious workflow from every branch, not just the default branch.
- Rotate all Actions secrets and every credential ever committed to any branch. Deleting a secret from the current tree does nothing for history.
- Audit workflow runs since August 31, 2026, the start of the earlier wave.
- Pause releases until the repository is clean. If PyPI, npm, crates.io, or container registry credentials were configured, assume they are compromised.
The publishing point deserves emphasis. As of the October 9 reports, no malicious package releases had been observed from the stolen credentials. StepSecurity warned that the absence of abuse so far is not evidence the credentials are safe. The pattern we covered in the LiteLLM 1.107.0 compromise shows how a stolen publishing path turns a secret leak into a package compromise.
Which settings would have blunted the attack?
Five repository settings reduce the damage. None is exotic, and each is available in standard GitHub plans.
- Require approval for workflow runs. StepSecurity observed this as the one control that stopped exfiltration in this campaign, in a case involving the typecho-fans/plugins repository.
- Protect the workflows folder. Use branch protection or a code owners rule so any change to
.github/workflows/*needs a reviewed pull request. - Block direct pushes to default branches for maintainers too, so a stolen token cannot write straight to main.
- Set the default
GITHUB_TOKENto read-only and grant write permissions per job. - Restrict runner egress with an allowlist, so a job cannot call an unknown IP address.
Pair those controls with lockfile-style pinning. Our how-to on GitHub Actions workflow lockfiles shows how to pin dependencies so a workflow cannot quietly change under you. Pinning does not stop a stolen maintainer token, but it narrows what an attacker can alter without a visible diff.
What if your own tokens may be exposed?
Start by shrinking the blast radius of every personal access token. Replace classic tokens with fine-grained ones scoped to specific repositories, set short expirations, and remove any token you no longer use. Check infostealer exposure by rotating credentials on any machine that may have been infected, because the initial theft likely happened there, not on GitHub.
Then add a signal for the next incident. Alert on workflow files created outside a pull request, and alert on commits to many repositories from one account within minutes. Those two rules would have flagged both October 8 windows. For a related case, see how the Shai-Hulud and Tensorlake npm compromise response handled credential rotation at scale. At Backtrace, we treat any unexpected workflow file as an incident until proven otherwise.
Finally, write the incident down. Record which repositories held the file, which secrets they could reach, and when each was rotated. A short log helps your auditors, and it helps the next on-call engineer answer whether a given key is safe to trust again.
Conclusion
GhostAction works because teams trust a workflow that looks like a security check. The defense is plain: search for the known files and markers, find out whether they ran, revoke the stolen token first, and rotate everything that history could expose. Then add approval gates, a protected workflows folder, and egress limits so a stolen token cannot do the same thing again.
Do the search tonight, across every organization you own. It takes minutes, and the cost of finding out later is a leaked production key.
