Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories

GhostAction Returns, Hijacking Two High-Profile Maintainer Accounts

A resurgence of the GhostAction credential-theft campaign compromised two high-profile open-source maintainer accounts on October 8, 2026, pushing a malicious GitHub Actions workflow into their repositories under the victims' own identities. The attacker first used the account of Takashi Kitao, author of the 18,400-star Python game engine pyxel, to push the workflow into 27 repositories starting at 13:20 UTC. Roughly eight hours later, the account of Henry Wu (GitHub handle henrywoo), the original author of Uber's athenadriver load-testing tool, was used to push the identical workflow into 318 repositories — 39 source repos plus 279 forks — in a 16-minute window between 21:10 and 21:26 UTC. Together the two accounts injected the payload into roughly 345 repositories in a single day, and researchers at Socket and StepSecurity say the activity is part of a much larger wave: more than 500 GitHub accounts have committed the same malicious workflow since October 7, 2026, with downstream fork inheritance and private-repository exposure pushing the campaign's real reach into the tens of thousands of repositories referenced in the headline figure.

What Happened

Both compromises followed an identical pattern: the attacker committed a new workflow file directly to each victim repository's default branch — no pull request, no review — disguised as routine CI/CD hygiene. The file was typically named .github/workflows/security-audit.yml (some variants used github_actions_security.yml), added via commits titled "Add security audit workflow" or "Update security audit workflow." Because the commits were signed with the compromised maintainers' own credentials, they carried the full trust of a legitimate project update, and GitHub's own activity feed showed Kitao and Wu as the authors.

The pyxel maintainer acknowledged the incident directly in a GitHub issue on the project, writing that the repository "was infected by a bad workflow by a compromised account" and confirming it as "part of the GhostAction campaign." As of October 9, 2026, Socket reported that the malicious workflow file remained present on the default branch of both flagship victims, meaning the compromise has not yet been cleaned up at the source.

How the Accounts Were Compromised

Neither Kitao nor Wu has published a root-cause confirmation, and researchers are careful to describe the entry point as probable rather than proven. The leading theory from Socket and StepSecurity is that the attacker obtained a leaked personal access token (PAT) for each account — most plausibly sourced from infostealer logs or credential dumps that circulate among multiple threat actors, rather than a targeted phishing operation against either maintainer specifically. That theory fits the pattern across GhostAction's prior waves: compromised accounts have had no reported connection to one another beyond both leaking a long-lived credential at some point, and the attacker's commits show no evidence of social engineering, fake build errors, or other interaction with the victims — the kind of lure researchers documented in the unrelated Axios and TanStack npm maintainer-account attacks earlier in 2026. Once a working PAT is in hand, the attacker needs no further access: GitHub PATs with repository write scope are sufficient to push commits to every repository the token's owner can write to, which is exactly the blast pattern observed — Wu's single token reached 318 repositories because that account had push access to each of them.

What the Malicious Workflow Does

The injected workflow runs a multi-stage credential harvest once triggered in CI:

1. Reconnaissance. The payload first scans the repository's existing workflow files for ${{ secrets.NAME }} references and templates the exact secret names it finds into itself before committing — meaning the attacker doesn't need to guess which secrets a given project uses. For pyxel specifically, which publishes to both PyPI and crates.io, this step surfaced publishing-credential secret names such as CARGO_REGISTRY_TOKEN, PYPI_PASSWORD, and a personal-access-token secret.
2. Full-history sweep. Unlike the original GhostAction wave, this version runs git log -p --all inside the job, walking every commit on every branch rather than just the current working tree. That means credentials that were committed and later deleted — a mistake most developers assume is "fixed" once the file is removed — remain fully exposed to the payload.
3. Pattern matching across roughly a dozen credential types. Socket's teardown found the workflow matches on AWS access keys, secret keys, and session tokens; Anthropic, OpenAI, and OpenRouter API keys; GitHub, GitLab, Google, and Firebase tokens; and Slack and SendGrid keys, pairing AWS key IDs with surrounding context lines so the full credential can be reconstructed from the exfiltrated text.
4. Exfiltration. The harvested data — named Actions secrets plus anything matched in the git history sweep — is sent via an unencrypted curl HTTP POST to a single hardcoded IP address, 193.32.204[.]199, on ports 80 and 3000, with a query parameter (?c=monami) apparently used to tag the batch.

Because the workflow runs under the repository's own CI permissions, it also has standing access to the job's GITHUB_TOKEN in addition to whatever secrets it names explicitly. Socket noted that, as of its reporting, no malicious package versions had been published to PyPI or crates.io using credentials stolen this way — but the publishing tokens were demonstrably collected, and the campaign's own history shows exfiltrated tokens have been reused later rather than immediately.

Scope of the Campaign

The headline figure of "tens of thousands" of repositories and the researcher-reported count of roughly 345 direct injections describe two different things, and conflating them overstates or understates the picture depending on which number is read in isolation:

• 345 repositories is the confirmed, direct blast radius of the two highest-profile compromised accounts — Kitao's and Wu's — in the single-day burst on October 8, 2026. This is the number with hard attribution: specific accounts, specific timestamps, specific repository lists.
• Tens of thousands of repositories is Socket's estimate of the campaign's total current reach, built from more than 500 GitHub accounts that have committed the same malicious workflow since October 7, 2026. Kitao and Wu are simply the two most recognizable names in a much larger, ongoing sweep; the other 498+ compromised accounts have lower individual repository counts but add up quickly, and fork inheritance (279 of Wu's 318 repos were forks, not originals) means a single compromised upstream can multiply the workflow's reach without any additional attacker effort.
• As of October 9, 2026, Socket's own spot-check found 378 repositories still hosting a live, default-branch copy of the malicious workflow, with 182 of those containing the newer git-history-mining markers — evidence that remediation across the broader wave is lagging well behind disclosure.

This is also not GhostAction's first appearance. The campaign was first disclosed in September 2025, when it hit 817 repositories across 327 GitHub users, exfiltrating 3,325 secrets including PyPI, npm, and DockerHub tokens. A second wave between August 31 and September 30, 2026 reached 772 public repositories belonging to 373 users and organizations. Separately, GitGuardian's review of that September 2026 wave found that only 124 repositories (16 percent) had been effectively cleaned in observed public history as of October 5, 2026 — a pattern of slow, partial remediation that the October wave appears to be repeating. A related but distinct incident tied to the same broader campaign saw the kuafuai/DevOpsGPT repository's Docker image altered to embed an XMRig cryptocurrency miner.

Why This Matters for Security Teams

1. Treat the two workflow filenames as an indicator of compromise, not a style choice. Any repository — your own, a fork, or a dependency you vendor — containing .github/workflows/security-audit.yml or github_actions_security.yml added since August 31, 2026 should be assumed compromised until proven otherwise, and the file removed from every branch, not just the default branch.
2. Rotate, don't just remove. Because the payload sweeps git log -p --all, deleting a secret from the current working tree does nothing to protect it if it was ever committed, even in a commit later squashed or force-pushed over. Rotate every credential that has ever appeared in the repository's history, not only the ones currently referenced in code.
3. Audit CI workflow diffs on every push, including your own maintainers'. A maintainer's own account pushing directly to the default branch, outside a pull request, is exactly the pattern this attack relies on to look legitimate — branch protection rules that require review even for repository owners would have caught both the pyxel and athenadriver injections before they ran.
4. Pin third-party GitHub Actions to a commit SHA, not a tag or branch, and extend the same scrutiny to your own workflow files — a workflow that suddenly starts running curl against a raw IP address, or executing git log -p --all, has no legitimate reason to do either.
5. Check forks, not just source repositories. 279 of the 318 repositories hit through the Wu account were forks; a compromised upstream can propagate the same malicious workflow to every fork that syncs from it.
6. Prefer short-lived, fine-grained tokens over long-lived personal access tokens. The probable entry point in both October compromises was a leaked PAT; fine-grained tokens with narrow scope and short expiry, or OIDC-based short-lived credentials, substantially reduce the value of a leaked secret to an attacker months or years later.

Sources

• Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories — The Hacker News

Related Reading

• GitHub Actions Re-Enabled With Mini Shai-Hulud Payload Still Active
• Compromised GitHub Actions Came Back Online and Resumed Executing Mini Shai-Hulud Malware
• Megalodon GitHub Attack Targets 5,561 Repos with Malicious CI/CD Workflows