Check your GitHub repos: A secret stealer hit tens of thousands of them
A threat actor using stolen GitHub credentials has pushed a credential-stealing payload into tens of thousands of repositories since November 10. In more than 1,800 of them, the malware ran and shipped GitHub Actions secrets and cloud credentials to the attacker. Aikido spotted the campaign and named it wfx-loot. The name comes from the attacker’s own labels, “wfx” for the malware and “loot” for what it steals.
Aikido counted 4,837 compromised accounts opening probe pull requests in 61,764 repositories. Of those pull requests, 10,431 went into repositories the account didn’t own, reached through collaborator or organization access, so one stolen token exposes every project its owner can write to. Ninety-two percent of the probe pull requests are still open.
The attacker cleans up within a minute
GitHub Actions runs automated jobs, called workflows, when code changes, and those jobs often hold keys to cloud accounts and package registries. The attacker first opens a pull request titled “docs: dependency audit notes” to confirm the token has write access. It then pushes a shell script of about 1,500 lines, injected into an existing workflow, hooked to npm install, or placed in a new workflow on a throwaway branch. Within a minute it reverts the change, then deletes the workflow run and its logs. Often all that’s left behind is a skipped number in the workflow’s run history.
It goes after the cloud
The script grabs Actions secrets, cloud and SSH credential files, shell histories, and tokens for AI tools including OpenAI, Anthropic, Cursor and Copilot. It uses what it finds to get into AWS, GCP and Azure, and creates long-lived AWS access keys.
It forges passing status checks to clear branch protection, rewrites an AWS role’s trust policy to accept any AWS account, and adds federated identity credentials to Azure applications. Those credentials let workflows in the compromised repository sign in to Azure after every token has been rotated.
Automated publishing triggers carried the payload into Packagist package digitalelvis/neuronai-studio 3.14.3 and Go module github.com/onuragtas/docker-env v1.0.278 and v1.0.280. In the Go tags it sits only in a workflow file, which Go builds never run. At least 50 compromised users appear to publish packages for npm, Go, Packagist, PyPI or crates, though Aikido assesses the attacker is focused on CI secrets.
Aikido says any machine that installed or opened the Packagist package should be treated as compromised.
How to tell if you’re affected
Look for a wfx-docs branch, the probe pull request, or commits titled “ci: refresh build cache,” “chore: add ci helper” or “chore: add dependency audit workflow.” If the payload ran, treat every secret and cloud role its workflows could reach as compromised. Missing wfx-loot artifacts prove little, because this campaign sent data straight to two attacker servers over HTTP. The script also has settings for private repositories, which suggests it may be running in places outside researchers can’t see.
Accounts hit by October’s GhostAction campaign were significantly more likely to be hit by wfx-loot, and in more than 100 repositories wfx-loot was injected into GhostAction’s own workflow files. Aikido assesses that the two are likely the work of different actors.
The AWS trust policy change and the Azure federated credentials survive secret rotation. Each one has to be tracked down and removed in every cloud account tied to the affected workflows.
GitHub Agentic Autofix: The question of who owns a bad AI patch
