GhostAction Returns, Hits 340+ Maintainer Repos

Two widely used open-source maintainer accounts have been hijacked and used to inject a credential-stealing GitHub Actions workflow into hundreds of repositories, according to researchers tracking a campaign they attribute to GhostAction. The activity marks a return of a supply chain operation that first surfaced in September 2025, this time running through the personal accounts of developers whose projects are used by other developers.

A Maintainer Account As the Entry Point

StepSecurity reported that an attacker took over the account of Takashi Kitao, the author of the 18,400-star game engine pyxel, and pushed a malicious workflow to 27 repositories beginning at 13:20 UTC. According to the researchers, eight hours later the account of Henry Wu (henrywoo), the original author of Uber's athenadriver, was used to push the same workflow to 318 repositories in a 16-minute window, between 21:10 and 21:26 UTC.

Socket said it has identified more than 500 GitHub accounts that committed the malicious workflow to tens of thousands of repositories since October 7, 2026. Across the two named accounts alone, the workflow reached more than 340 repositories, though the wider count is substantially larger.

The pattern depends on the victim's own identity. Because the workflow is pushed under the maintainer's account, it arrives in the repository looking like ordinary commit activity rather than an external intrusion.

The Workflow Is Built to Look Routine

The injected files carry innocuous names — Security Audit ("security-audit.yml") or GitHub Actions Security ("github_actions_security.yml") — and are designed to send sensitive data to a hard-coded IP address, 193.32.204[.]199, over plain HTTP.

StepSecurity described the trigger and checkout configuration in detail. According to the researchers, the workflow "triggers on workflow_dispatch and an unfiltered push (any branch, any tag), checks out with fetch-depth: 0, and runs a single 'Audit' step that does four things."

Those four actions, as enumerated by StepSecurity, are:

• Append the repository's named secrets found during reconnaissance
• Scan the working tree for 13 credential patterns associated with AWS keys, AI services, source control services, and SaaS and cloud API keys
• Check the entire git history for the same 13 patterns to harvest credentials that may have inadvertently been committed to the repository and subsequently deleted
• Pair AWS access key IDs with their matching secret access keys

The data the payload captures includes the repository's named GitHub Actions secrets, including CI/CD secrets, along with cloud, AI, and SaaS credentials present in the working tree and the entire git history — AWS keys, Anthropic, OpenAI, and OpenRouter API keys, and GitHub and GitLab tokens among them.

"Using the account of Takashi Kitao, author of the 18,400-star game engine pyxel, the attacker pushed a malicious workflow to 27 repositories starting at 13:20 UTC. Eight hours later, the account of Henry Wu (henrywoo), the original author of Uber's athenadriver, was used to push the same workflow to 318 repositories in a 16-minute window, 21:10–21:26 UTC."

— StepSecurity

How the Credentials Are Obtained

The attack chain runs in four stages, according to the researchers. First, the attacker obtains a maintainer's GitHub credentials — most likely a leaked personal access token (PAT) taken from infostealer logs or credential dumps. The repository's workflow files are then scanned for secrets as a reconnaissance step.

Next, a workflow masquerading as a security audit is injected into the default branch under the victim's own identity. Finally, the embedded payload extracts the data and sends it to an attacker-controlled endpoint via curl.

Because the reconnaissance step precedes the injection, the payload can be tuned to what is actually present in the repository rather than casting a generic net, and because the checkout uses fetch-depth: 0, the payload can reach deleted history as well as the current working tree.

Forks Inherit the Problem

The malicious file does not stay confined to the repository where it was first pushed. Socket noted that the 279 forks in the henrywoo namespace each carry the workflow file.

"The 279 forks in the henrywoo namespace each carry the workflow file. If Actions are enabled, subsequent pushes can trigger credential harvesting. Downstream forks are also at risk if they inherit the malicious workflow, either when newly created or by synchronizing with the affected upstream repository."

— Socket

That propagation matters for how the campaign spreads. A fork that is later synchronized with its upstream can pull the workflow in even if the fork's owner never touched the file directly. In repositories where GitHub Actions are enabled, later pushes can set the harvesting step running again.

Socket also described which repositories carry the greatest exposure, and what the operator collects on every run.

"Private forks and downstream mirrors are the most exposed, because private repositories are where committed credentials are actually found. Across both accounts, every run also returns a repository identifier whether or not credentials were found, so the operator holds a map of reachable execution contexts independent of any credential theft."

— Socket

Prior Phases of the Same Campaign

This is not the first wave of the operation. GhostAction first came to light in September 2025, when the activity impacted 817 repositories across 327 GitHub users and resulted in the exfiltration of 3,325 secrets through compromised developer accounts. Those stolen secrets included PyPI, npm, and DockerHub tokens.

Earlier in the week, GitGuardian reported that the GhostAction campaign pushed the malicious workflow to 772 public repositories belonging to 373 GitHub users and organizations between August 31 and September 30, 2026. The injected workflows target 2,577 secrets, including SSH private keys, Azure credentials, DockerHub and GHCR container registry credentials, database credentials, AWS access keys, FTP credentials, Google Cloud and Firebase credentials, GitHub tokens, Telegram, Slack, and Discord bot tokens, and keys associated with Cloudflare, npm, PyPI, and AI providers.

The campaign has also shown a second payload in at least one instance. In a case observed on August 30, 2026, the threat actors altered the "kuafuai/DevOpsGPT" repository to embed an XMRig cryptocurrency miner in the project's Docker image. As of writing, no malicious package releases have been published using compromised publishing credentials.

What Was Taken, by the Numbers

• More than 340 repositories reached through the two named maintainer accounts
• 27 repositories pushed via the Takashi Kitao account, beginning at 13:20 UTC
• 318 repositories pushed via the Henry Wu (henrywoo) account in a 16-minute window, 21:10–21:26 UTC
• More than 500 GitHub accounts identified by Socket as committing the workflow since October 7, 2026
• 817 repositories across 327 GitHub users impacted in the September 2025 phase
• 3,325 secrets exfiltrated in that earlier phase
• 772 public repositories across 373 GitHub users and organizations in the GitGuardian-observed window of August 31 to September 30, 2026
• 2,577 secrets targeted by the injected workflows, per GitGuardian
• 13 credential patterns scanned in both the working tree and git history
• 279 forks in the henrywoo namespace carrying the workflow file

The Advice for Affected Developers

Developers are advised to check their repositories for either of the two workflows — "security-audit.yml" or "github_actions_security.yml" — since August 31, 2026, and to assume compromise if either file is present.

The recommended remediation steps are to revoke the compromised GitHub credential, rotate credentials, delete the malicious workflow from all branches, and check forks of the infected repositories.

Rotation matters because the payload reaches beyond the secrets a repository declares by name. Because it scans the working tree and the full git history for the same 13 patterns, credentials that were committed and later deleted can still be recovered from history, and AWS key IDs can be paired with their matching secret access keys.

Why the Forked Copies Matter

The mechanics of the campaign make the usual advice — clean up the repository where you found the file — insufficient on its own. A workflow file carried into a fork is subject to the same trigger conditions as the original, and synchronization with an affected upstream can reintroduce it.

Private forks and downstream mirrors draw particular attention in Socket's assessment because, as the researchers put it, private repositories are where committed credentials are actually found. A private fork that inherited the workflow would hold the same harvesting logic in an environment more likely to contain live secrets.

On the operator's side, Socket's account describes data collection that continues regardless of whether any credentials turn up: every run returns a repository identifier, so the operator accumulates a record of reachable execution contexts even when a given run yields nothing to steal.

What This Means for Anyone Running Actions

For teams that build and ship software through GitHub Actions, this campaign places the burden on the account and workflow layer rather than on a dependency or package. The entry point is a maintainer credential, the payload rides in as a workflow file under the maintainer's own identity, and the trigger fires on pushes to any branch or tag.

That combination means the practical checks are identity- and configuration-focused. Teams could verify whether either workflow name appears anywhere in their repository history since August 31, 2026, and treat a match as a compromise rather than a curiosity. They could also review which credentials a repository's workflows can reach, since the payload's value depends on what is available to it at runtime.

The fork dimension suggests downstream users may want to look beyond the repository they administer. A fork created or synchronized from an affected upstream can carry the workflow file without its owner having committed anything. Organizations inheriting projects from the two named maintainer accounts face the same question in mirrored or private copies.

Because the campaign ran through multiple phases — the September 2025 wave, the August 31 to September 30, 2026 window reported by GitGuardian, and the October 2026 pushes described by StepSecurity and Socket — the relevant exposure window for checking repositories extends back further than the most recent pushes. Developers who find either workflow file and have not yet rotated their credentials are left with the possibility that any secret reachable from that repository has already been transmitted over plain HTTP to the address 193.32.204[.]199.

For the broader open-source ecosystem, the campaign illustrates a dependency that is not addressed by reviewing package contents: the trust placed in a maintainer's account and in the workflow files that run under it. That trust is what the operator appears to be exploiting, and it is the layer that repository owners can inspect and harden directly.