GhostAction: Fake Security Audit Workflows Now Sweep Git History for AI Keys

A workflow file called “security audit” sounds like something you’d want in your repository. In the GhostAction campaign, it is the attack. Security firm Socket reported on Oct. 9 that a new wave, running since Oct. 7, had pushed the fake workflow from more than 500 GitHub accounts, and that it now hunts for AWS keys and AI-service keys hidden anywhere in a repository’s history. The point for developers is uncomfortable: a key you removed from your code years ago may still be sitting in a commit, and this variant goes looking for it.

Where it stands: In its Oct. 9 update, Socket said it had found “more than 500 GitHub accounts that committed the malicious workflow to tens of thousands of repositories since October 7, 2026.” At that point the file was still on the default branch of repositories Socket checked, and Socket had seen no malicious package releases on PyPI or crates.io as a result. Other security vendors have published different counts for different time windows; the figures here are Socket’s.

What GhostAction is

GhostAction is not new. GitGuardian says it discovered the campaign on Sept. 5, 2025, and that in that first round “attackers compromised 327 GitHub user accounts to inject malicious workflows that stole 3,325 secrets from CI/CD environments across 817 repositories.” The stolen material included package-registry tokens, GitHub tokens, AWS keys and database credentials, and GitGuardian said affected developers confirmed attackers were using some of them.

The method has stayed the same. An attacker gets into a maintainer’s GitHub account, then commits a workflow file with an official-sounding name to every repository that account can write to. GitHub Actions runs it automatically, and the job ships secrets to a server the attacker controls. Socket is blunt about the payload: “The workflow has no security function.”

How the maintainer accounts are compromised is still unclear. In Socket’s words: “Socket did not observe how.”

What changed in the October 2026 GhostAction wave

“Earlier waves took only what was stored in GitHub Actions secrets,” Socket wrote. The new version still does that, and it “adds a regex sweep for cloud provider and AI service credentials committed into the repository and its complete git history.”

The difference matters. Actions secrets are values a project deliberately stores for its build pipeline. Committed credentials are mistakes: a key pasted into a config file, an .env file pushed by accident, a token deleted in a later commit but never revoked. The workflow fetches every branch and tag, then reads the full patch history. Socket notes that keys pulled from old commits are ones “the maintainer most likely believes are gone.”

Socket studied one burst on Oct. 8 in detail, in which two compromised maintainer accounts dropped the file into 346 repositories, including an Uber-owned project and the widely starred kitao/pyxel. It said the two most-starred repositories in one account’s set are machine-learning projects whose contributors typically hold “AWS keys and Anthropic, OpenAI, and OpenRouter API keys.”

Which keys it looks for

Socket published the 13 credential patterns the sweep searches for, in both the current files and the history. Grouped by what they unlock:

The AWS handling is the most deliberate part, according to Socket. The workflow captures a couple of lines around every AWS key ID so it can pair the ID with the secret that usually sits next to it in a config file, producing a working key pair rather than half of one.

Socket also warns that private repositories face the bigger risk: “Private forks and downstream mirrors are the most exposed, because private repositories are where committed credentials are actually found.”

How to check a repository for GhostAction

Socket’s guidance, condensed, for anyone who maintains or forks code on GitHub:

1. Look for the file. Check .github/workflows/ for security-audit.yml or github_actions_security.yml that you did not add, and search commit history for the messages “Add security audit workflow,” “Update security audit workflow” or “Add Github Actions Security workflow.”
2. Read the Actions run history. Socket’s rule: “Treat any completed run as successful exfiltration of the named secrets.”
3. Scan the whole history, not just the latest commit. Run a secrets scanner across all branches and tags (for example, over git log -p --all). Socket says to “treat anything that ever appeared in a commit as exposed regardless of whether it appears in the current tree.”
4. Revoke, then replace. Rotate every credential the workflow named and every key the history scan finds. For personal access tokens, Socket recommends revocation rather than rotation.
5. Lock down the account. If your account pushed the file, treat it as fully compromised: revoke sessions, tokens, OAuth grants and SSH keys, then switch to phishing-resistant multi-factor authentication.
6. Remove the workflow and revert the commit everywhere it landed, including organization repositories the account can write to.
7. Check forks before enabling Actions, and block the attacker’s collection server in egress logs. Socket lists the address as 193.32.204[.]199.
8. Turn on GitHub’s secret scanning and push protection, and make workflows triggered by outside contributors wait for a maintainer’s approval.

If you published packages from an affected repository, compare release history on PyPI, npm or crates.io against your own builds. Our guide to checking whether application secrets were leaked covers how to read provider logs once you know which keys were exposed.

Rotate the right thing

The two halves of the payload need different responses. Socket put it plainly: “Rotating Actions secrets does nothing for a committed-credential exposure, and scanning the working tree does nothing for an Actions-secret exposure.” A team that only resets its CI secrets can miss an old OpenAI key buried in a past commit, and a team that only scans current files can miss a stolen PyPI token.

What GitHub and AI providers do automatically

Some leaked keys get caught for you. GitHub says that when a partner’s secret appears in a public repository, it “forwards it to the relevant partner so they can revoke or rotate the credential before it can be abused.” Anthropic says it “automatically deactivates the exposed API key” when GitHub reports one, and OpenRouter says it is a GitHub secret scanning partner too. On Oct. 13, GitHub began blocking new Anthropic key types with push protection by default.

That net has holes for this campaign. Partner forwarding, as GitHub describes it, covers public repositories, and GhostAction reads the history of private repositories it reaches as well. And because the workflow sends keys straight to the attacker’s server rather than posting them anywhere public, there may be nothing new for a public-repo scanner to catch.

A separate case from Railway

GhostAction surfaced the same month as Railway’s Oct. 21 disclosure about customer environment variables, and both involve stolen developer secrets. No source links them. For Railway users, the GitHub angle is different: Railway reset the GitHub tokens it held, and this walkthrough on Railway and GitHub tokens explains what users still have to do themselves. Socket counted 279 forks in one compromised account’s namespace that each carry the GhostAction file, and it warned that later pushes can trigger the credential harvest wherever Actions are enabled.

Frequently Asked Questions

What is the GhostAction campaign?

GhostAction is a GitHub supply chain campaign in which attackers use stolen maintainer accounts to commit a fake security workflow that sends secrets to a server they control. GitGuardian first documented it in September 2025. Socket reported a new wave starting October 7, 2026 that also searches the code and its git history for cloud and AI keys.

How do I know if my GitHub repo was hit by GhostAction?

Look in .github/workflows for files named security-audit.yml or github_actions_security.yml that you did not add, and for commits titled Add security audit workflow, Update security audit workflow or Add Github Actions Security workflow. Then check the Actions run history. Socket says any completed run should be treated as successful theft.

I deleted an old API key from my code. Is it still at risk?

Yes, if it is still in the git history. The new GhostAction variant reads every branch and tag, including past commits. Revoke or rotate any key that was ever committed, even if it no longer appears in the current files.

Will GitHub secret scanning protect my AI keys?

It helps. GitHub forwards provider secrets found in public repositories to partners such as Anthropic and OpenRouter, which can deactivate them, and push protection can block some keys before they are committed. That forwarding is described for public repositories, so keys in private repositories need your own scanning and rotation.

Does GhostAction have anything to do with Railway?

Nothing published so far ties the two together. GhostAction is a separate campaign that works through compromised GitHub accounts. Railway has not said how its own incident happened.

Sources

• New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials — Socket Research Team, October 9, 2026
• The GhostAction Campaign: 3,325 Secrets Stolen Through Compromised GitHub Workflows — GitGuardian, September 2025 (updated October 6, 2026)
• Secret scanning blocks Anthropic keys by default, adds Salesforce — GitHub Changelog, October 13, 2026
• API key best practices: keep your keys safe and secure — Anthropic (Claude Help Center), undated help article (fetched October 21, 2026)
• API Authentication – Secure Access to OpenRouter — OpenRouter documentation, undated docs page (fetched October 21, 2026)
• Security Disclosure Recommendation: Redeploy Buckets and Reconnect GitHub After the Credential Reset — Railway (Mykal Machon), October 22, 2026

This article is news reporting and general security information based on the public sources listed above, as they stood on the dates shown. Incident details often change as investigations continue; check the affected company’s own status page and notices for the latest. Data Breach Radar is not affiliated with any company named here.