GhostAction plants a credential-stealing workflow in tens of thousands of GitHub repositories
The GhostAction campaign compromises maintainer accounts to push a fake “security” workflow that exfiltrates CI/CD secrets to an attacker-controlled IP. Check your repos for security-audit.yml and github_actions_security.yml, then revoke any affected credentials.
7 October 2026. The GhostAction campaign is back: more than 500 GitHub accounts have pushed a malicious workflow into tens of thousands of repositories, according to Socket. 9 October 2026. StepSecurity details two compromised maintainer accounts — Takashi Kitao, author of the pyxel game engine (18,400 stars), and Henry Wu, the original author of Uber’s athenadriver. 9 October 2026. GitGuardian tallies 772 public repositories and 2,577 secrets harvested between 31 August and 30 September. Why it matters: the attacker does not exploit a product flaw — they hijack the maintainer’s identity, the hardest link in a CI/CD chain to monitor.
The entry point is not a bug, it is a token
GhostAction is not new. The campaign has been documented since September 2025, when it hit 817 repositories across 327 accounts and exfiltrated 3,325 secrets — PyPI, npm and DockerHub tokens. Its playbook has not changed: the attacker obtains a maintainer’s credentials, most likely a personal access token (PAT) leaked in infostealer logs or credential dumps.
From there, everything happens under the victim’s legitimate identity. Takashi Kitao’s account pushed the malicious workflow to 27 repositories starting at 13:20 UTC. Eight hours later, Henry Wu’s account did the same across 318 repositories in a 16-minute window, between 21:10 and 21:26 UTC. That speed is not the signature of an exploit — it is the speed of an authenticated push.
The implication is brutal: protections that rely on the committer’s identity — code review, branch protection, signature requirements — are bypassed, because the committer is the maintainer themselves.
What the workflow actually does
The injected workflow carries a reassuring name: security-audit.yml or github_actions_security.yml. It presents itself as a security audit while doing the opposite — exfiltrating sensitive data to a hard-coded IP address, 193.32.204[.]199, over plain HTTP.
Its trigger is broad: workflow_dispatch and an unfiltered push (any branch, any tag). It checks out with fetch-depth: 0 — the entire Git history — then runs a single “Audit” step that does four things, per StepSecurity:
- Appends the repository’s named secrets spotted during reconnaissance;
- Scans the working tree for 13 credential patterns (AWS keys, AI services, source control, SaaS and cloud API keys);
- Traverses the full Git history for the same 13 patterns, harvesting credentials that were committed by mistake and later deleted;
- Pairs AWS access key IDs with their matching secret access keys.
The harvest is broad by design: named GitHub Actions secrets, CI/CD credentials, AWS keys, Anthropic, OpenAI and OpenRouter keys, and GitHub and GitLab tokens. Exfiltrating over plain HTTP to a bare IP says something about the attacker’s confidence — the operation targets volume, not network discretion.
An industrial harvest, not a surgical one
GitGuardian’s numbers show the scale. Between 31 August and 30 September 2026, the malicious workflow was pushed to 772 public repositories owned by 373 accounts and organisations. It targeted 2,577 secrets: SSH private keys, Azure credentials, DockerHub and GHCR registries, databases, AWS keys, FTP, Google Cloud and Firebase, GitHub tokens, Telegram, Slack and Discord bot tokens, and Cloudflare, npm, PyPI and AI-provider keys.
The campaign did not stay strictly within exfiltration. In at least one case, on 30 August, the attackers modified the kuafuai/DevOpsGPT repository to embed an XMRig miner in the project’s Docker image. So far no malicious package releases have been made with the stolen publishing credentials — but the harvested PyPI and npm tokens are a time bomb: they allow poisoning a legitimate package at the moment of the attacker’s choosing.
One detail makes it more worrying still. Socket notes that the 279 forks of the henrywoo account each inherit the workflow file. If Actions are enabled on a fork, a later push can trigger the harvest. Private forks and downstream mirrors are the most exposed, because private repositories are where committed credentials actually live. Worse: every run returns a repository identifier whether or not a secret is found — so the operator keeps a map of reachable execution contexts, independent of any credential theft.
What GhostAction changes compared with tag hijacking
The reflex would be to file GhostAction alongside the tag hijacking attacks that hit tj-actions or Nx. That would be a category error. Tag hijacking relies on the deferred resolution of a reference: uses: actions/checkout@v4 points at a mutable commit, and the attacker repositions the tag. The documented defence is SHA pinning.
GhostAction plays a different game. The malicious workflow is not a dependency resolved at build time: it is committed directly into the repository, on the default branch, under the legitimate maintainer’s identity. No pinning protects against that, because there is nothing to pin — the malicious file is just another source file.
The consequence is that the “classic” supply chain defences — commit signing, code review, branch protection — lose their power when the attacker owns the account. The reviewer sees a maintainer’s push; the signature is valid; the branch is protected but the owner is legitimately pushing. That is exactly the blind spot GhostAction has exploited since September 2025.
The lesson is therefore not “pin your actions” — necessary as that remains — but “protect your maintainers’ credentials as the border they are”. A leaked PAT is already half the attack done.
What to do
Remediation combines an immediate check with credential rotation, in that order.
- Look for the two workflow files. Since 31 August 2026, any presence of
security-audit.ymlorgithub_actions_security.ymlin a repository must be treated as a confirmed compromise. - Delete the workflow from every branch. The file can sit on the default branch or on side branches. Remove it everywhere, including in forks.
- Revoke and rotate credentials. Revoke the compromised GitHub token, then rotate every exposed secret — AWS, AI providers, container registries, SaaS.
- Audit the forks. Check forks of infected repositories: they inherit the workflow and can reactivate it in turn.
- Harden the pipeline. Pin actions by SHA, restrict
GITHUB_TOKENpermissions, and distrust any workflow triggered byworkflow_dispatchcombined with an unfiltered push.
The trap of this kind of campaign is that it leaves no suspicious build trace: the workflow carries a legitimate name and runs inside the victim’s own infrastructure, with their own rights.
For defenders, the campaign also leaves a detectable signature even before the workflow is found: a workflow triggered on workflow_dispatch combined with an unfiltered push, doing a full-history checkout and curling data to a bare IP, is unusual. Alerting on that pattern — and on any outbound request from a workflow to an IP with no hostname — turns the attacker’s own exfiltration channel into a tripwire.
Verdict
If you maintain a public or open-source repository, audit it today for the two workflow names and treat any occurrence as a compromise: revoke the PAT, rotate secrets and purge the file from every branch. If you manage secrets in GitHub Actions, assume a compromised maintainer equals exposed secrets — scope permissions, pin actions and watch for broad triggers. GhostAction proves it once more: in supply chain, the most profitable flaw is not in the code, it is in the credentials of the people who publish it.