GhostAction: 1,900 hijacked GitHub accounts, 30,000 repositories, and a workflow called "Security Audit"

Background

GitHub Actions lets a repository run automated jobs — builds, tests, deployments — whenever code is pushed. Those jobs routinely hold secrets: cloud access keys, package-registry tokens, API keys for AI providers. Anyone who can commit a workflow file to a repository can, in principle, make those jobs do something else with those secrets.

GhostAction was first documented by GitGuardian in September 2025, when it stole 3,325 secrets across 817 repositories. It never fully stopped. In 2026 it came back in waves, each larger than the last, culminating in a burst on October 8–9 that touched more than 30,000 repositories.

From one leaked token to secrets on an attacker's server

What actually happened

From August 31, 2026, GitGuardian observed a malicious workflow being pushed to public repositories — 772 of them across 373 users and organizations by September 30. The commits were made under the victims' own GitHub identities. The workflow, named security-audit.yml or github_actions_security.yml, was configured to run on every push and on manual trigger. It read the repository's GitHub Actions secrets by name (the operator first extracted which secret names each repository used and hardcoded them into the payload), checked out the full git history, scanned the working tree and every past commit for credential patterns — AWS keys, GitHub and GitLab tokens, Google and Firebase keys, and Anthropic, OpenAI and OpenRouter API keys — and sent what it found in a single plain HTTP POST to an attacker-controlled server.

Across those 772 repositories, the workflows targeted 2,577 secrets. But GitHub held most workflow runs for approval. Of 3,669 runs GitGuardian collected across 605 repositories, only 499 actually executed, in 32 repositories, and 336 completed — exfiltrating 26 secrets from 13 repositories. By October 5, only 124 of the 772 repositories (16%) had been effectively cleaned; in 92 cases the attacker simply edited a malicious workflow left behind by an earlier wave.

Then the campaign escalated. On October 8, the account of Takashi Kitao, author of the 18,400-star pyxel game engine, pushed the workflow to 27 repositories starting at 13:20 UTC. Eight hours later, the account of Henry Wu, original author of Uber's athenadriver, pushed it to 318 repositories in sixteen minutes — under three seconds per repository. Within the same window the payload went to 160 previously hit victims and then, twenty minutes later, to about 28,000 new repositories. GitGuardian's tally of the October burst: more than 30,000 repositories across roughly 3,000 users and organizations, about 1,900 compromised accounts and 3,174 targeted secrets. GitHub began blocking the workflow from running on October 9; further waves with the same payload followed on October 10 and 12.

Every run also reported the repository's identity back to the operator, whether or not it found credentials — giving the attacker a running map of repositories where their code executes. Private forks and downstream mirrors carrying the workflow remain the most exposed, because private repositories are where committed credentials tend to live.

Root cause

Timeline

Detection

What to monitor for in your own environment

Containment, eradication & recovery

Security control analysis

Controls that would have prevented or limited this

Blast radius

How GitHub's approval gate thinned the August–September wave

What they got right

GitHub's run-approval requirement measurably limited the damage — the clearest evidence in this incident that platform defaults matter.

Security researchers at GitGuardian, StepSecurity and Socket tracked the campaign continuously and published workflow names, payload shape and search queries, so maintainers could check their own repositories.

GitHub moved to block the specific workflow from running on October 9, within a day of the largest burst.

Why this keeps happening

Personal access tokens leak constantly — into infostealer logs, public repos, CI output — and many are long-lived with broad repository access.

Workflow files are code that runs with access to secrets, but most teams don't review changes to them as carefully as application code.

Cleanup is incomplete: when only 16% of affected repositories are cleaned, attackers simply return to the ones still carrying their workflow.

Lessons for your own environment

1. A developer token is a key to your pipeline, not just your code

   With a stolen token, an attacker can commit a workflow that runs with your secrets. Treat tokens as privileged credentials: short-lived, scoped, monitored.

2. Review workflow changes like production code

   The attack lived entirely in .github/workflows. CODEOWNERS and PR review on that directory turn a silent compromise into a visible diff.

3. Don't store what you can federate

   OIDC workload identity means there are no long-lived cloud keys sitting in Actions secrets for a workflow to dump.

4. Your git history is a credentials archive

   The payload scanned every past commit. A key removed from the current code but still in history is still exposed.

5. Keep platform guardrails on

   Workflow-run approval stopped most of this campaign. It is worth the friction.

6. Finish the cleanup — every branch, every fork, every secret

   Attackers re-used 92 workflows victims never removed. Incomplete recovery invites the next wave.

CISO & board lessons

• Ask engineering for the number of active classic or long-lived personal access tokens with broad repository access. That number is your exposure to the next GhostAction wave.
• Make OIDC federation the default for CI-to-cloud authentication, and set a deadline for retiring stored cloud keys in CI secrets.
• Require CODEOWNERS review for workflow directories across the organization, and keep GitHub's workflow-approval settings at their protective defaults.
• Treat a supply-chain alert as a rotation event, not a deletion event: deleting the workflow does nothing for secrets that already left.
• Track cleanup to completion with a metric — percentage of affected repositories, branches and forks verified clean — rather than closing the ticket when the first fix lands.

Action plan

Could this happen in your organization?

• Would a direct push of a new workflow file to your default branch be blocked, reviewed or at least alerted on?
• How many long-lived cloud or AI API keys are stored as CI secrets today?
• Have you scanned the full git history of your repositories for credentials, not just the current code?
• Can your CI runners make outbound HTTP requests to any IP on the internet?
• Do your developers use fine-grained, expiring tokens, and would you know if one appeared in an infostealer log?
• If you were hit in an earlier wave, can you prove every branch and fork has been cleaned?

If this happened to you: what to ask, and what to say

Knowing the lesson isn’t the same as knowing what to do with it Monday morning. A security lead, a CISO, and a customer-facing team each need something different from this incident.