GhostAction hit 318 repositories in 16 minutes

Using the GitHub account of Henry Wu (henrywoo), original author of Uber’s athenadriver, an attacker pushed an identical malicious workflow to 318 repositories in a 16-minute window, 21:10 to 21:26 UTC, StepSecurity reported. Eight hours earlier the same operator had used the account of Takashi Kitao, author of the 18,400-star pyxel game engine, to push the same workflow to 27 repositories starting at 13:20 UTC. Socket puts the broader total far higher: more than 500 GitHub accounts committed the workflow to tens of thousands of repositories since October 7, 2026.

This is GhostAction, the supply chain campaign first reported in September 2025. That earlier round hit 817 repositories across 327 users and exfiltrated 3,325 secrets, including PyPI, npm, and DockerHub tokens. GitGuardian counted another 772 public repositories across 373 users and organizations between August 31 and September 30, 2026, targeting 2,577 secrets.

The workflow lands under a file named security-audit.yml or github_actions_security.yml, committed to the default branch under the maintainer’s own identity. It triggers on workflow_dispatch and on an unfiltered push (any branch, any tag), checks out with fetch-depth: 0, and runs a single step called Audit. That step appends the repository’s named Actions secrets (identified during a reconnaissance pass over the workflow files), scans the working tree for 13 credential patterns, scans the full git history for the same 13 patterns, and pairs AWS access key IDs with their matching secret keys. Everything goes to a hard-coded IP, 193.32.204.199, over plain HTTP via curl.

The patterns cover AWS keys, AI providers (Anthropic, OpenAI, OpenRouter), source control tokens (GitHub, GitLab), and a range of SaaS and cloud credentials. GitGuardian’s tally from the earlier wave adds SSH private keys, Azure, GHCR, database, FTP, Google Cloud and Firebase credentials, and Telegram, Slack, and Discord bot tokens.

The git-history scan is the part that catches people. fetch-depth: 0 pulls the complete history, so a key that was committed by mistake and removed in a later commit is still there to harvest. Rotating only the secrets currently in your Actions settings does not cover that.

How the accounts get taken over: StepSecurity assesses the attacker most likely starts with a leaked personal access token from infostealer logs or credential dumps. With the token, they scan the repo’s workflow files, then inject the audit workflow under the victim’s identity. No GitHub vulnerability is involved; the PAT is the whole key.

So far no one has published a malicious package release using the stolen publishing credentials, which points at credential harvesting as the goal rather than immediate supply chain propagation. StepSecurity’s caveat is the one to keep: the absence of abuse so far is not evidence that the credentials are safe. Socket adds a second reason the operator comes out ahead even when a run finds nothing. Every execution returns a repository identifier regardless of whether it captured credentials, so the attacker ends up with a map of reachable execution contexts.

Forks are where this keeps spreading. The 279 forks in the henrywoo namespace each carry the workflow file, and if Actions are enabled, a subsequent push can trigger harvesting. Downstream forks inherit the workflow when they are created or when they sync from the affected upstream. Socket’s point about private forks is the sharpest: private repositories are where committed credentials actually tend to live, so a private mirror of a compromised project is the most exposed of all.

If you maintain or fork anything that might sit downstream of this, check for security-audit.yml or github_actions_security.yml dating to August 31, 2026 or later. Treat either as a compromise. Revoke the GitHub credential that pushed it, rotate every secret the workflow could have reached (including ones that only ever appeared in git history, not just current Actions secrets), delete the workflow from every branch and tag, and check your forks.

One case sits apart from the rest. On August 30, 2026 the kuafuai/DevOpsGPT repository was altered to embed an XMRig miner in the project’s Docker image. GitGuardian found no other repository carrying that miner, its config, or its wallet, and notes GhostAction hit hundreds of repositories within hours while this was a single surgical change to one repo using the same compromised account. They do not attribute the miner to the GhostAction actors.