Security firm Aikido has published details of wfx-loot, an active campaign in which an attacker logs in with stolen GitHub credentials and slips a secret-stealing payload into repositories those accounts can write to. Aikido says the activity started around 12:45 UTC on November 10, 2026, and its report went out on November 12.
The numbers are large. Aikido counted 4,837 compromised accounts opening probe pull requests in 61,764 repositories, and it found signs that the payload actually ran in at least 1,806 of them. Because the stealer targets GitHub Actions secrets and cloud credentials, teams whose developers can push to a hit repository need to act quickly.
How the attack works
There is no typosquatted package or dependency trick. The attacker acts as a real developer, using that person's tokens and their normal write access, including access to repositories owned by organisations where the developer is a collaborator. By Aikido's count, more than 10,000 probe pull requests went to repositories that belonged to someone other than the hijacked user.
Each target goes through the same short cycle, which Endor Labs says takes roughly a minute per repository:
- Probe: a pull request titled docs: dependency audit notes, opened from a wfx-docs branch, confirms write access.
- Payload: one of three variants is pushed, either a roughly 1,500-line injection into an existing workflow, a shell script wired to an npm postinstall hook, or a new workflow file on a throwaway chore/ branch.
- Cleanup: a revert commit follows within seconds or a minute, and the run record is wiped along with its logs.
That cleanup step is why many owners have not noticed. Aikido notes that around 92% of the probe pull requests were still open, and that a gap in a workflow's run numbers is often the only remaining sign that the payload executed.
What the stealer takes
The payload is one heavily commented shell script that names itself wfx. According to Aikido's analysis, it reads every Actions secret and variable, the workflow token, OIDC tokens, environment variables and well-known credential files for AWS, Azure, Google Cloud, Docker, Kubernetes, npm, PyPI, SSH and more.
It also looks for API keys belonging to AI providers and AI coding tools, scans home directories for files such as .env, .pem and kubeconfig, and reads the memory of runner processes to pull out tokens. On self-hosted runners it goes further and queries cloud instance metadata.
The script then tries to escalate. It swaps GitHub OIDC tokens for AWS, Google Cloud and Azure sessions, creates long-lived AWS access keys, impersonates Google service accounts and lists Azure Key Vaults.
Persistence that survives key rotation
The most worrying part is what the script leaves behind. Aikido describes three persistence steps:
- Forged success statuses that reuse the names of the repository's required checks, which satisfies branch protection rules.
- An AWS role trust policy rewritten to allow any AWS account to assume it.
- New federated identity credentials, with names starting wfx-ci-, added to Azure AD applications so the compromised repository can sign in without a stored secret.
In this wave, the stolen bundle was sent by HTTP POST to attacker servers on port 8080. Aikido stresses that finding no wfx-loot artifacts, cache entries or step summaries does not prove that nothing was taken.
Packages affected so far
Most of the damage sits in repositories, not registries, but the payload reached two published packages through automated release triggers. One is version 3.14.3 of the Packagist package digitalelvis/neuronai-studio, and Aikido advises treating any machine that installed it as compromised.
The other is the Go module github.com/onuragtas/docker-env at v1.0.278 and v1.0.280, where the payload sits only in a workflow file. Endor Labs adds that at least 50 hijacked accounts publish to npm, Go, Packagist, PyPI or crates, which raises the risk of a second wave of poisoned releases.
What it means for developers
Start by searching every repository you can write to for the indicators. Signs include a wfx-docs branch and the docs: dependency audit notes pull request. Watch also for short-lived chore/ branches ending in eight random characters, plus any of these commit messages:
- chore: add dependency audit workflow (new workflow file)
- ci: refresh build cache (edited workflow)
- ci: cleanup or ci: restore (the reverts)
- chore: add ci helper (npm install hook)
Searching commit history matters more than scanning current code, since the payload stays on the branch for only seconds.
If the payload ran, treat all credentials and cloud roles reachable from that repository's pipelines as stolen. Rotate them, but also remove the attacker's back doors: review AWS role trust policies, check Azure app registrations for unknown federated credentials, and audit recent status checks on protected branches.
Longer term, this campaign is a reminder to cut standing access. Short-lived tokens, narrow workflow permissions, OIDC roles scoped to specific branches and pinned actions all shrink the blast radius. Our earlier report on GitHub Actions workflow lockfiles covers one way to tighten what your pipelines run.
Conclusion
wfx-loot turns stolen developer logins into a quiet, fast way to drain CI secrets and plant cloud back doors, then hides its tracks within a minute. Any team with contributors who may have leaked tokens should check commit history and run-number gaps now, rotate exposed credentials and clean up the persistence the stealer leaves behind.
Sources
- Aikido Security: wfx-loot campaign pushes CI secret stealer to tens of thousands of repositories
- Endor Labs: Hijacked GitHub Accounts Push wfx CI Secret Stealer to Thousands of Repositories
See my articles more often when you search Google.
