WFX: hijacked GitHub accounts push a CI secret stealer into thousands of repositories

An attacker holding stolen credentials for thousands of GitHub accounts has spent the last two days pushing a secret stealer into every repository those accounts can write to. The stealer runs inside GitHub Actions, collects the secrets and cloud credentials the workflow can reach, and then the attacker reverts the commit and deletes the workflow run. Security firms Aikido and StepSecurity both published analyses on 12 November. The script calls itself “wfx”.

How big it is

The numbers depend on who counted and how, so here they are by source:

• Aikido: 4,837 compromised accounts opened probe pull requests in 61,764 repositories, starting around 12:45 UTC on 10 November. Aikido counts at least 1,835 repositories where the payload ran and credentials were taken, and says that likely understates it because the logs were deleted. 10,431 of the probes went into repositories the account does not own, through collaborator or organisation access, and 92% of those were still open when Aikido checked.
• StepSecurity: as of 07:40 UTC on 12 November, GitHub search returned more than 63,000 probe pull requests, about 90% still open, with new ones “still appearing every few minutes”.
• SafeDep, as reported by The Hacker News: 8,093 public repositories received malicious commits on default branches up to 04:36 UTC on 12 November, 771 of them through an npm postinstall hook that also fires on a developer’s machine.

Nobody has said how the attacker got the credentials. Bot accounts matter as much as people here: in two cases StepSecurity describes, the token belonged to a project’s automation account, and one of those bots could bypass branch protection.

How it works

1. Probe. A pull request titled docs: dependency audit notes from a wfx-docs branch confirms write access. Aikido says any account that opened one should be treated as compromised, even if nothing followed.
2. Push. The stealer arrives as a commit titled ci: refresh build cache (about 1,500 lines added to an existing workflow), chore: add ci helper (a hidden .ci-*.sh script plus a postinstall hook), or chore: add dependency audit workflow on a short-lived chore/ branch. StepSecurity also found it pasted into shell scripts CI already runs, such as update.sh.
3. Collect and escalate. Per Aikido, it takes every Actions secret and variable, the GITHUB_TOKEN, OIDC tokens, credential files, AI provider keys and secrets from runner process memory. It then trades OIDC tokens for AWS, GCP and Azure sessions.
4. Persist. It can open an AWS role’s trust policy to any account and add federated credentials named wfx-ci-* to Azure AD apps, which survive secret rotation. It also posts forged “success” checks so branch protection lets the commit through.
5. Clean up. A ci: restore revert usually lands within a minute and the run is deleted. A gap in the run numbers is often the only trace.

StepSecurity adds that since about 05:30 UTC on 12 November, new copies send stolen data only to a Telegram chat, so blocking the published IP addresses no longer stops it.

What to check today

• Search your orgs for wfx-docs branches, the probe PR title and the commit titles above, from 10 November onward.
• Look for missing run numbers in Actions history around those commits.
• If the stealer ran, rotate every secret and cloud role the workflow could reach, revoke the committing account’s tokens, OAuth grants, SSH keys and sessions, and check for wfx-ci-* Entra ID credentials and changed AWS trust policies.
• Pin any package you consume that was published from an affected repo. Aikido lists a Packagist and a Go module so far.

Our earlier piece on GitHub’s pull_request_target brownouts and workflow lockfiles covers the hardening side, and the NEBULA npm case shows why install hooks on developer machines are a target too.

Why this matters

Agent and RAG pipelines put model API keys and cloud roles inside CI, and this stealer looks for exactly those. The attack needs no bug, only an account with write access, including bots. Treat write access and bypass rights for automation accounts as secrets in their own right, and keep workflow secrets scoped to the jobs that need them.