GhostAction Returns: Fake Security Audit Workflows Steal Keys

GhostAction, a GitHub Actions credential-theft campaign first documented in September 2025, is back with a new payload that steals secrets from a repository's entire git history, not just its configured Actions secrets. StepSecurity and Socket both published analyses on October 9 showing attackers using hijacked maintainer accounts to push a fake security audit workflow, and Socket counts more than 500 accounts committing it to tens of thousands of repositories since October 7. If a workflow with that name showed up in anything you maintain, treat it as a breach — rotating your current secrets won't be enough.

Key Takeaways

• The new payload (security-audit.yml) sweeps the working tree and the full git history for 13 credential patterns, including AWS, Anthropic, OpenAI, and OpenRouter keys, then sends everything to a hard-coded IP over plain HTTP
• On October 8, hijacked accounts belonging to the author of the pyxel game engine and the original author of Uber's athenadriver were used to push the workflow to roughly 345 repositories in two short bursts
• StepSecurity's code search still showed 378 repositories carrying the workflow on a default branch as of October 9, and both firms report no malicious package releases so far
• Because the payload reads history, rotating current Actions secrets no longer covers the exposure — any credential that was ever committed should be treated as stolen
• In one observed case, a repository that required approval for workflow runs stopped the exfiltration entirely

What is GhostAction, and what changed this time?

GhostAction is a campaign of malicious GitHub Actions workflows pushed into repositories from compromised developer accounts. StepSecurity first covered it in September 2025, when it stole more than 3,000 secrets across 817 repositories. The delivery method hasn't changed: a workflow with a plausible name, committed straight to the default branch under the victim's own identity. StepSecurity says the older payload is still being deployed alongside the new one.

What's new is how much the payload takes. The earlier version only sent a repository's configured Actions secrets. The October version also hunts for credentials in the code itself and in every commit ever made, which reaches secrets a maintainer deleted years ago and assumed were gone.

How does the attack work?

StepSecurity describes four stages. First, the attacker gets a maintainer's GitHub credential, most plausibly a personal access token leaked through infostealer logs or credential dumps (Socket says it didn't observe how). Second, the attacker scans the repo's existing workflows for the secret names they reference and bakes those names into the payload. Third, the workflow lands directly on the default branch, and the injection push itself triggers it. Fourth, it posts whatever it finds to an attacker-controlled server with curl.

The October variant, named Security Audit (security-audit.yml), triggers on manual dispatch and on any push to any branch or tag. It checks out with full history (fetch-depth: 0), then runs a single step that does four things: it adds the repo's named secrets, greps the working tree for 13 credential patterns, greps the entire git history for the same patterns, and captures the lines around every AWS access key ID so the matching secret key comes along. Everything leaves in one request.

The 13 patterns cover AWS access keys and session tokens, Anthropic, OpenAI, and OpenRouter API keys, GitHub and GitLab tokens, Google and Firebase API keys, Slack tokens, and SendGrid keys. AI provider keys are now a first-class target. The AWS context capture matters because a key ID alone authenticates nothing; the secret half usually sits a line or two away in an env file, a credentials file, or a CI config.

The trigger block of the Security Audit variant is a quick tell when you're skimming workflow files:

name: Security Audit
on:
workflow_dispatch:
push:

Who has been hit so far?

On October 8, the attacker used the account of Takashi Kitao, author of the roughly 18,400-star game engine pyxel, to push the workflow to 27 repositories starting at 13:20 UTC. The workflow templated pyxel's PyPI and crates.io publishing credentials plus a personal access token, a direct path to shipping a poisoned release of a trusted library. StepSecurity's run history shows the workflow executing five times, two of them manual re-runs triggered from the compromised session, which suggests a person was actually at the keyboard.

Eight hours later, the account of Henry Wu (henrywoo), original author of Uber's athenadriver, was used to push the same workflow to more than 300 repositories in a 16-minute window, 21:10 to 21:26 UTC. That sweep reached uber/athenadriver, where Wu still had write access. The commit went straight to master with no pull request and no review, under his real identity and unsigned, so nothing in the audit log looked odd unless you read the file. StepSecurity pulled the run log and confirmed the exfiltration completed: the attacker's server acknowledged the request four seconds after the run started. That run's GITHUB_TOKEN was read-only for contents, which limited what the workflow itself could do but didn't stop it from sending stolen data out.

The campaign is still live. As of October 9, a GitHub code search for the attacker's IP in workflow files returned 378 repositories with the workflow on a default branch, according to StepSecurity (an approximate count that excludes forks and drifts as people clean up). Socket's broader count is more than 500 accounts committing the workflow to tens of thousands of repositories since October 7. Both firms report that no malicious package versions have been published from the stolen credentials so far, but StepSecurity stresses that the absence of abuse isn't evidence the credentials are safe.

How do you check whether you're affected?

StepSecurity published GitHub code search queries you can run across all of GitHub or scoped to your organization. A zero-result search is a good sign; any hit means an infected repository or a fork carrying the workflow. Code search only indexes default branches and skips forks, so check your forks separately.

# Across GitHub
"AKIA_CTX_START" path:.github/workflows
"c=monami"
"193.32.204.199" path:.github/workflows

# Your organization (replace your-org)
org:your-org "AKIA_CTX_START"
org:your-org "c=monami"
org:your-org "193.32.204.199"

Also look for workflow files named security-audit.yml, github_actions_security.yml, or security-check.yml, and for commits with messages like "Add security audit workflow". Check workflow runs since August 31, 2026. A completed run of either fake workflow means the data left, because it beacons on every execution even when it finds nothing. In your audit log, watch for workflow files added directly to default branches without a pull request, and for rapid unsigned commits across many repositories within minutes.

What should you do if you find the workflow?

StepSecurity's and Socket's remediation advice lines up closely:

• Rotate every credential the history sweep could reach: all Actions secrets plus anything ever committed to any branch, including AWS keys, AI provider keys, GitHub and GitLab tokens, and Slack and SendGrid keys. Deleting a secret from the current tree changes nothing, because the payload reads old commits.
• Revoke the compromised GitHub credential itself, since that's the injection path. Socket also recommends revoking all sessions, tokens, OAuth grants, and SSH keys on the account, then re-enrolling with phishing-resistant MFA.
• Delete the workflow from every branch, not just the default one. It triggers on pushes to any branch, and the sweep reads all refs.
• Treat any completed run as confirmed exfiltration, and check egress logs, including self-hosted runners, for connections to 193.32.204[.]199.
• Hold off on releases until you're clean. If PyPI, npm, crates.io, or container registry credentials were configured, assume the attacker can publish as you, and review your registry's release history for versions you didn't ship.
• Check forks and cloud logs. Forks of infected repos carry the workflow, so look before enabling Actions on one, and review CloudTrail for any AWS keys found in your history.

How do you harden your repos against this?

StepSecurity saw one control actually stopping this campaign. In typecho-fans/plugins, which had been infected since September 5, the compromised account pushed commits on October 7 purely to re-trigger the workflow. The repository required approval for workflow runs, so both runs stalled and the exfiltration never executed. Requiring approval where you can is the cheapest fix on the list.

Between them, the two firms also recommend protecting .github/workflows with branch protection so workflow changes need a reviewed pull request, restricting runner egress to an allowlist (the payload posts to a bare IP over plain HTTP, so domain-based filtering never sees it), and turning on secret scanning with push protection so credentials don't land in history in the first place.

Developer credentials keep showing up as the way in. For another example of a compromised developer environment turning into a supply chain problem, see how GitHub was breached through a VS Code extension.

Wrapping Up

Whether or not you've seen this workflow, run the three code search queries against your organization today, and treat any hit as a full credential compromise, history included. Then turn on push protection and workflow approval gates so the next wave has a harder time.

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