An attacker using stolen GitHub credentials has pushed a credential stealer into tens of thousands of repositories since Nov. 10, according to research from Aikido Security, which tracks the campaign as wfx-loot.
Aikido counted 4,837 hijacked accounts opening test pull requests in 61,764 repositories and found signs the stealer ran in at least 1,835, a figure it said may understate the impact. At least 50 of the hijacked accounts belong to people who appear to publish packages to registries such as npm, PyPI and crates.
The test was a pull request called “docs: dependency audit notes,” opened from a branch named “wfx-docs.” If it went through, the stealer arrived soon after, hidden in an existing workflow, an npm install hook or a new workflow on a throwaway branch.
Within a minute, the attacker reverted the change and deleted the workflow run along with its logs, often leaving a gap in the run numbering as the only clue.
Fake Green Checks and Back Doors Into the Cloud
Once running, the script collected almost anything a CI job could reach, including repository secrets, the workflow’s GitHub tokens, cloud and developer-tool credential files, AI service keys, shell histories and secrets held in the memory of other processes. On self-hosted runners, it also went after cloud instance metadata.
It could also trade GitHub’s identity tokens for sessions in AWS, Google Cloud and Azure, mint long-lived AWS keys and pose as Google Cloud service accounts.
Before most of its collection began, the payload also reported its own commit as having passed the repository’s required checks, reusing their names. Because branch protection looked at a check’s name rather than at which app reported it, the fake results could satisfy merge rules.
To keep access after credentials were rotated, the script could open an AWS role to any AWS account by rewriting its trust policy. It could also register new federated credentials, named “wfx-ci-,” on Azure applications, so the compromised repository kept Azure access with no stored secret.
A Gap in the Run History May Be the Only Clue
Aikido said that where the payload ran, teams should “assume every secret and cloud role available to its workflows is compromised.” It advised owners to search any repository they can write to for the wfx-docs branch, the test pull request title and the commit messages the campaign used.
An account that only opened the test pull request should also be treated as compromised, Aikido said. It added that a missing run number on the attacker’s commit was a more reliable sign that the payload ran than other artifacts, whose absence “does not mean data was not taken.”
The stealer also reached a Packagist package and two tags of a Go module through automated publishing, though Aikido noted that Go builds never execute the workflow file holding the payload.
Some of the accounts had also been hit in October’s GhostAction wave, but Aikido assessed the two as distinct campaigns, likely carried out by different threat actors.
Of the 10,431 test pull requests opened in repositories the attacker’s accounts did not own, 92% were still open when Aikido published, which the company said suggested most owners had not noticed.
