GitHub Hack Uses 4,837 Stolen Accounts to Loot CI Secrets
The stealer ran in at least 1,806 repos and wipes its own logs within a minute, so many teams may not know their cloud keys are gone. Here is how to check.
Hakkı ALKANPublished 5 min read
A GitHub hack that started on Nov. 10, 2026 used 4,837 stolen developer accounts to plant a secret stealer in repositories those accounts could write to. The malware grabs CI passwords, API keys and cloud credentials, then the attacker deletes the evidence within about a minute.
Aikido Security, which first reported the campaign and named it wfx-loot, says the stealer ran in at least 1,806 repositories, where credentials have most likely already been taken. Because the attacker reached many projects through collaborator and organization access, a repository can be hit even if its owner's own account was never touched.
How did the GitHub hack work?
Every attack began with a test. The attacker opened a pull request titled "docs: dependency audit notes" from a branch named wfx-docs, just to confirm the stolen account could write to the repository. Aikido counted these probes in 61,764 repositories. 10,431 of them landed in projects the account does not own, and 92% were still open, which suggests most owners have not noticed.
Where the probe worked, the real payload followed. The target was GitHub Actions, GitHub's built-in system for CI (continuous integration), the automated jobs that test and build code on every push. The roughly 1,500-line shell script arrived in one of three ways: injected into an existing workflow with the commit message "ci: refresh build cache", added as a new workflow on a short-lived chore/ branch, or hidden behind an npm postinstall hook, a script that runs automatically whenever someone types npm install. That last route also runs on a developer's own laptop.
After the run, the attacker reverted the commit and deleted the workflow run along with its logs. In many repositories, a missing run number is the only trace left.
What does the stealer take?
Practically everything the CI job can reach. According to SafeDep's analysis, the script collects:
- All repository secrets and variables, the GITHUB_TOKEN and Actions runtime tokens
- GitHub, AWS, OpenAI, Anthropic and other API keys found in the runner's memory
- Credential files for AWS, Azure, Google Cloud, Kubernetes, npm, PyPI and SSH, plus crypto wallets and AI tool configs
- Files such as .env, *.tfvars and *.tfstate inside the repository
It also requests GitHub OIDC tokens, short-lived identity tokens that let a workflow log into cloud accounts without a stored password, and tries to use them against AWS, Azure, Google Cloud, HashiCorp Vault and Kubernetes. In AWS and Azure it tries to leave backdoors, such as Azure federated credentials prefixed wfx-ci-, that keep working after secrets are rotated.
On self-hosted runners, the CI machines companies operate themselves, it can also pull cloud metadata credentials and container secrets. Stolen data went out over HTTP or to a Telegram chat; about a fifth of 200 sampled commits used Telegram only.
Developer keys have become a favorite target this month. Days earlier, the Railway hack stole AI keys from cloud workspaces, and Claude Code users learned that a "Don't Ask Again" button could push their secrets into public repos.
How big is the damage?
The numbers depend on what each firm counted:
| Source | What was counted | Number |
|---|---|---|
| Aikido Security | Accounts that opened probe pull requests | 4,837 |
| Aikido Security | Repositories where the stealer ran | At least 1,806 |
| SafeDep | Public repos with malicious commits on default branches (Nov. 10 to 12) | 8,093 |
| GitGuardian | Payload patches in its own dataset | 28,500 across 17,715 repos |
SafeDep says its figure covers only default branches of public repositories, so the real total is higher. At least 50 of the compromised users publish packages to npm, Go, Packagist, PyPI or crates, and the payload has already shipped inside a Packagist package and two tagged versions of a Go module.
Why did GitHub's safety net miss part of it?
GitHub did block much of the attack. GitGuardian reports that every November payload run it could observe in the workflow-file variants was put on "action_required" hold and never started. The npm hook avoided that check because it changes no workflow file: the repository's own trusted workflows run npm install, which quietly runs the hidden script. GitGuardian found public logs from 19 repositories where the script executed, 18 of them reporting a successful upload. Hook commits jumped from 10 to 70 per three hours to 1,210 on the morning of Nov. 12.
How the accounts were stolen is still unknown, and GitHub had not published a statement on its blog or changelog as of Nov. 13. Aikido saw overlap with October's GhostAction campaign but does not attribute both to the same actor.
How can you check if your repository was hit?
- Search for a wfx-docs branch or a pull request titled "docs: dependency audit notes" since Nov. 10. Its presence alone means the author account is compromised.
- Look for commits named "ci: refresh build cache", "chore: add ci helper" or "chore: add dependency audit workflow", and gaps in workflow run numbers.
- Revoke that account's tokens, OAuth grants, SSH keys and sessions, and turn on 2FA.
- Rotate every secret the repository can read, including environment and organization secrets.
- Check cloud accounts for wfx-prefixed roles and federated credentials; rotation alone will not remove them.
- If you ran npm install on an affected commit, treat that machine as compromised.
Our take
The clever part of this GitHub hack is not the malware but the route around GitHub's approval gate. Platforms have learned to flag edited workflow files; they have not yet learned to distrust an ordinary npm install that a trusted workflow runs every day.
The same pattern sits behind the recent wave of developer-targeted attacks, including North Korea's FaceStealer video-call scam: attackers go after the people and tools with keys, not the servers. Put simply, a single leaked token from a hobby repo with write access to your organization is enough to put your cloud account at risk. Until GitHub explains how so many tokens leaked, teams should treat any account with write access as a possible entry point and keep CI secrets scoped as narrowly as possible.