GhostAction Returns: Maintainer Takeover Steals Workflow Secrets

Key Takeaways

On October 8, 2026, an attacker used two compromised maintainer accounts to push a credential-stealing GitHub Actions workflow into 345 repositories across two windows of 24 and 16 minutes, according to StepSecurity [1]. The workflow reuses the filenames and “security audit” framing of the original GhostAction campaign disclosed in September 2025 [3], which suggests either the same operator or a copycat working from public reporting; because the original campaign’s details were public, the reuse is weak evidence on its own. The attribution question is unresolved in the sources reviewed.

The new variant has broader collection capability than its predecessor in one respect. Instead of reading only a fixed list of named repository secrets, it also runs git log -p --all over the full checkout and scans every commit on every branch for thirteen credential patterns, including AWS keys, GitHub and GitLab tokens, and API keys for AI providers such as Anthropic and OpenAI [1][2]. Rotating the secrets currently stored in a repository therefore does not close the exposure, because credentials that were committed and later deleted remain recoverable from history.

Reported scale varies by source. StepSecurity counts about 378 repositories with active malicious workflows as of October 9 [1], while Socket, as relayed by The Hacker News, reports more than 500 GitHub accounts committing the workflow to “tens of thousands of repositories” since October 7 [2]. These figures have not been reconciled, and defenders should treat the higher figure as a plausible upper bound rather than a confirmed count.

Organizations should immediately search their GitHub estate for the indicators in the Recommendations section, remove the workflow from every branch and fork, rotate every secret that has ever appeared in repository history, and review any recent maintainer-account activity for unexpected workflow commits.

Background

GhostAction was first documented by GitGuardian in September 2025. In that campaign, attackers compromised maintainer accounts, including the account behind the FastUUID project, and committed a workflow disguised as “Github Actions Security.” The workflow triggered on push or manual dispatch, read named secrets from the repository’s Actions environment, and sent them by HTTP POST to an attacker-controlled domain [3]. GitGuardian reported that 327 GitHub users and 817 repositories were affected and that 3,325 secrets were stolen, including PyPI, npm, DockerHub, GitHub, Cloudflare, and AWS credentials [3][4]. At the time, GitGuardian identified 24 packages (9 npm and 15 PyPI) at risk of malicious release through the stolen publishing tokens, and reported active exploitation of some AWS and database credentials [3][4].

The October 2026 reporting describes a second phase that appears to build on that template. StepSecurity’s analysis, published on October 9, documents the takeover of two maintainer accounts on October 8: the account of Takashi Kitao, author of the pyxel game engine (about 18,400 stars), and the account of Henry Wu, original author of Uber’s athenadriver [1]. Kitao’s account was used from 13:20 to 13:44 UTC to push the workflow to 27 repositories. Wu’s account was used from 21:10 to 21:26 UTC to push it to 318 repositories, made up of 39 source repositories and 279 forks [1]. The Hacker News additionally attributes to GitGuardian a count of 772 public repositories belonging to 373 users and organizations between August 31 and September 30, 2026, with 2,577 secrets targeted [2]. We have not independently reviewed GitGuardian’s primary write-up of that period, and the relationship between that activity and the October 7–9 burst is not clear from the sources available.

The sources do not establish how the maintainer accounts were compromised. StepSecurity describes a leaked personal access token from infostealer logs or credential dumps as the most plausible explanation, which is an inference rather than an observed finding [1]. The same pattern, a credential harvested weeks earlier and used later, appears in CSA’s analysis of the June 2026 Miasma incident, where an employee’s GitHub account credentials were present in infostealer logs nearly seven weeks before the malicious releases [5].

Security Analysis

Attack Chain

The attack has three stages. First, the operator obtains write access to a maintainer’s GitHub identity. Second, using that access, the operator commits a workflow file under .github/workflows/ with a name chosen to resemble routine hygiene: security-audit.yml or github_actions_security.yml, with commit messages such as “Add security audit workflow” and “Trigger security scan” [1]. Third, the workflow executes on the runner, where Actions secrets are available to the job, and sends harvested data to 193.32.204.199 over plain HTTP [1][2]. StepSecurity confirmed one exfiltration in a run against uber/athenadriver, where the curl call received an OK response from the server four seconds after the job started [1].

Because the attacker commits through a legitimate maintainer identity, many of the traditional pull-request-based controls teams rely on for detecting malicious contributions have little to examine. There is no pull request from an unknown account, no typosquatted dependency, and no vulnerability in GitHub Actions itself. The workflow runs with exactly the permissions the repository owner granted, and the commit appears in the history under a trusted name. The incident is, in that sense, an account compromise that the CI/CD platform’s normal behavior turns into a secrets-disclosure event.

Git-History Mining

The 2026 variant’s principal change is its search of repository history. Setting fetch-depth: 0 causes the checkout step to retrieve all history, and git log -p --all then emits every patch on every branch. The workflow applies thirteen patterns to that output, covering AWS keys, AI provider tokens (Anthropic, OpenAI, and, per secondary reporting, OpenRouter), GitHub personal access tokens, GitLab tokens, Google and Firebase keys, Slack tokens, and SendGrid keys [1][2]. For AWS, it also captures surrounding lines near AKIA and ASIA prefixes so that an access key ID can be paired with its secret key, using the markers AKIA_CTX_START and AKIA_CTX_END in the exfiltrated body [1].

This matters because, in practice, credentials that were committed and later deleted are frequently left unrotated. Those credentials were never in the Actions secrets store, so a defender scoping exposure to “the secrets configured on this repository” would underestimate the loss. Secret-scanning tools may flag such leaks, but an alert can be closed as resolved once the file is removed even though the credential remains valid. The campaign effectively turns any unrotated historical leak that matches its patterns into an exploitable one, provided the attacker can get a workflow to run.

The workflow reports back with two URL markers. Requests carrying /?c=monami indicate that named secrets were found, and /?c=new indicates that only history-derived matches were present [1]. These markers may help defenders correlate egress logs with affected repositories.

Targets and Impact

AI provider keys are one category among many in the pattern set, and the sources do not show that the attacker selected victims by AI relevance. LLM API keys can be monetized directly, resold, or used to run workloads on the victim’s account, and they can sit alongside cloud and registry credentials in the same .env history. The affected projects reported so far include several AI-related repositories, such as henrywoo/pyllama and henrywoo/chatllama [1].

As of publication of StepSecurity’s analysis, no weaponized package releases using harvested publishing credentials had been observed [1]. That is a statement about the observation window, not about risk. Stolen npm or PyPI tokens can remain valid until they are rotated, and the 2025 campaign involved stolen publishing tokens for dozens of packages [3]. The June 2026 Mastra incident, in which a stale contributor account retained publish rights and was used to backdoor roughly 144 packages, illustrates how a dormant credential can become a distribution channel [6].

Forks and Persistence

Of the 318 repositories modified through Henry Wu’s account, 279 were forks [1]. Forks inherit workflow files and, if they carry their own secrets, execute them under the fork owner’s settings. A cleanup limited to default branches or upstream repositories can therefore leave live copies elsewhere. StepSecurity recommends removing the workflow from all branches and checking forks and mirrors for inherited copies [1].

Evidence Quality

The primary technical detail comes from a single vendor analysis, StepSecurity [1], which includes a public workflow run as supporting evidence. The wider scale claims come from Socket via press coverage [2] and have not been corroborated in the sources reviewed. Readers should also note that some secondary articles blend the 2025 and 2026 campaigns, including statistics from both, so counts should be traced to their primary publisher before being reused.

Recommendations

Immediate Actions

Search for the campaign’s indicators across your organization’s repositories and audit logs. StepSecurity suggests code searches for AKIA_CTX_START and 193.32.204.199 within .github/workflows, and a search for c=monami within the organization [1]. Block 193.32.204.199 at network egress where runners are self-hosted, and review workflow runs since at least August 31, 2026, the start of the earlier activity period reported by GitGuardian via The Hacker News [2], for jobs created from commits titled “Add security audit workflow” or “Trigger security scan” [1].

If a malicious workflow is found, revoke the credential that allowed the commit, delete the workflow from every branch, check forks, and pause releases from the affected repositories until they are verified clean. Then rotate every secret that has ever been committed to any branch, not only the Actions secrets currently configured, and prioritize cloud access keys, package-registry tokens, and AI provider keys [1]. For maintainers, rotate personal access tokens and review the account’s recent commits and token activity even if no malicious workflow is visible, since a compromised account may have been used in ways not yet discovered.

Short-Term Mitigations

Require pull request review for any change under .github/workflows/, enforced through branch protection or rulesets and CODEOWNERS, so a single compromised account cannot add a workflow and run it without a second approver. Replace long-lived cloud keys in Actions with OpenID Connect federation scoped to repository, branch, and environment, which reduces the value of a stolen secret [7]. Set the default GITHUB_TOKEN to read-only and gate publishing credentials behind protected environments with required reviewers. Prefer fine-grained, short-lived tokens over classic personal access tokens, and require phishing-resistant MFA for maintainers and organization members.

Run secret scanning with push protection, and treat any alert for a historical secret as requiring rotation instead of closure after deletion. Where feasible, alert on new workflow files created by accounts that have not previously modified CI configuration, and on outbound HTTP from runners to bare IP addresses.

Strategic Considerations

The campaign shows that credentials in version-control history are a durable liability. Organizations may consider a one-time historical secrets sweep across repositories, with rotation as the default outcome, followed by a policy that removes the need to store long-lived secrets in repositories at all. For open-source projects that publish packages, trusted-publishing mechanisms and release workflows that require manual approval limit what a single hijacked maintainer can ship. Organizations that depend on open-source maintainers should also recognize that those individuals’ account hygiene is part of their supply chain, and should favor dependencies whose projects document multi-maintainer review and token practices.

Finally, teams should inventory where AI provider keys live. Because LLM keys can be present in developer repositories and CI environments, they warrant the same lifecycle management, scoping, and spend monitoring applied to cloud credentials.

CSA Resource Alignment

CSA’s Miasma: Red Hat npm Supply Chain Worm is the closest prior analysis. It documents a stolen GitHub credential, a gap between infostealer exposure and weaponization, and abuse of GitHub Actions OIDC, which parallels the account-takeover and workflow-abuse path described here and supports the recommendations on federated credentials and rapid token rotation [5]. CSA’s Mastra npm Scope Takeover examines how a stale contributor account with publish rights was used to backdoor an AI framework, and informs the guidance on maintainer access reviews and the downstream risk of harvested publishing tokens [6].

For control mapping, the AI Controls Matrix (AICM) v1.1 is the primary control framework for this analysis. Its identity and access management domain bears on maintainer authentication and token scoping, and its application and interface security and threat and vulnerability management domains bear on pipeline integrity and secrets handling [8].

References

[1] StepSecurity. “GhostAction Returns: Malicious ‘Security Audit’ Workflows Now Mine Credentials from Entire Git Histories.” StepSecurity, October 9, 2026.

[2] The Hacker News. “Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories.” The Hacker News, October 9, 2026.

[3] GitGuardian. “GhostAction Campaign: 3,325 Secrets Stolen.” GitGuardian Blog, September 2025.

[4] SecurityWeek. “GitHub Workflows Attack Affects Hundreds of Repos, Thousands of Secrets.” SecurityWeek, September 8, 2025.

[5] Cloud Security Alliance. “Miasma: Red Hat npm Supply Chain Worm.” CSA, June 2026.

[6] Cloud Security Alliance. “Mastra npm Scope Takeover: AI Framework Supply Chain Backdoored.” CSA, June 2026.

[7] GitHub. “Security hardening for GitHub Actions.” GitHub Docs.

[8] Cloud Security Alliance. “AI Controls Matrix v1.1.” CSA.