Stolen GitHub tokens push CI secret-stealer to 60,000 repos

An attacker used roughly 4,800 compromised GitHub accounts to submit probe pull requests to 61,764 repositories and run a CI secret-stealer in more than 1,800 of them, according to overlapping analyses from Aikido Security, StepSecurity and SafeDep. Aikido, which named the campaign wfx-loot, says it began on 10 November. SecurityWeek first aggregated the three reports.

No vulnerability — valid tokens

StepSecurity is explicit: "The attacker does not exploit a bug in GitHub Actions." The campaign runs on valid tokens belonging to developer and bot accounts. StepSecurity traced 173 probe pull requests to tokens issued to the Fly.io GitHub app, but could not determine how the tokens were obtained and found no evidence Fly.io's own infrastructure was breached. The probe pull requests test whether the stolen access can modify a repository; as StepSecurity puts it, "the pull request does nothing by itself."

What runs when access works

Where permissions allow, the attacker injects a stealer into one of three places:

• Existing or new GitHub Actions workflows
• Shell scripts run by CI systems
• npm install hooks — which also exposes developers who install the affected dependencies

The script hunts for GitHub tokens, repository secrets, cloud credentials and AI service keys, reads GitHub Actions runner process memory, and carries functionality to expand access and persist in AWS and Azure. The attacker then reverts the code changes and deletes the workflow runs to hide the activity. SafeDep counted 8,093 public repositories that received malicious commits — a number it cautions "does not necessarily indicate successful execution." The payload was also pushed through a Packagist package and tagged versions of two Go modules.

Action checklist

1. If the stealer ran in your CI, treat every reachable secret as compromised. Aikido's guidance is to assume full exposure, not to triage.
2. Revoke and rotate: GitHub personal-access and app tokens, repository and organization secrets, and any cloud credentials or AI service keys referenced in your pipelines.
3. Review recent CI history for probe pull requests from unfamiliar accounts, workflow edits that were reverted, and deleted workflow runs — the attacker cleaned up after itself.
4. Check AWS and Azure for unauthorized access-key creation, new principals or role changes dated from 10 November.
5. Lock down install hooks. Pin dependencies, review postinstall/preinstall scripts, and prefer --ignore-scripts in CI where feasible.
6. Scope tokens down. Short-lived, least-privilege tokens limit what a single stolen credential can reach.

Context

Aikido notes the tooling and targeting resemble the GhostAction campaign from October but assesses the two probably involve different actors. Either way it is the second mass CI-secret sweep across public GitHub in as many months, and it rhymes with the stolen-token registry takeover in Red Hat Quay disclosed the same day: attackers have settled on the build-and-distribution plane as the highest-leverage target, and they are increasingly doing it with valid credentials rather than exploits. That shifts the defensive burden onto secret hygiene, token scoping and CI audit trails — controls that don't show up in a CVE feed.