wfx-loot Campaign Hit Thousands of GitHub Repositories Using Stolen Accounts

The wfx-loot campaign abused compromised GitHub accounts to spread malware targeting secrets in CI environments. According to an analysis by Aikido Security, the activity began on November 10, 2026. The attacker used 4,837 compromised accounts to create test pull requests in 61,764 repositories, and the malicious code reportedly executed in at least 1,806 of them.

This is not confirmed exploitation of a GitHub Actions vulnerability. Available technical analyses point to the use of valid but stolen tokens and account permissions. It has not yet been publicly established how the attacker obtained these tokens and credentials.

How the wfx-loot campaign used test pull requests

One visible indicator was a pull request titled docs: dependency audit notes, created from the wfx-docs branch. Such a pull request does not, by itself, execute malicious code. Its purpose was to verify whether the stolen token could write to a particular repository.

The presence of a test pull request therefore indicates the compromise of an account with access to the repository, not necessarily the theft of secrets from that project. To execute the secret stealer, a malicious change had to be inserted into code or configuration and then run.

SafeDep independently identified 8,093 public repositories with malicious commits. This figure should not be interpreted as the number of successful payload executions: a malicious commit may have been removed, or the workflow may not have run. The number of affected private repositories and cases with deleted traces may be higher.

How the CI secret stealer entered projects

StepSecurity’s analysis confirmed three main malware-insertion paths. The attacker modified GitHub Actions workflows, existing shell scripts, or added a postinstall hook to the package.json file. The last method extends the risk beyond CI itself: malicious code may run on a developer’s device if the user executes npm install on a commit containing the modified package.

The malware collected secrets available to the specific CI job, GitHub Actions tokens, and cloud credentials. When execution is confirmed, tokens, secrets, and cloud roles available to the workflow should be considered potentially compromised.

According to the findings, the attacker often subsequently reverted the changes and deleted workflow-run records. This reduced the incident’s visibility. Gaps in GitHub Actions run numbering may be among the signals that should be checked when reviewing history.

What repository administrators should check

Organizations should review commit, pull request, and workflow history for the campaign period. Reported indicators of compromise include the wfx-docs branch, the name docs: dependency audit notes, and the commits ci: refresh build cache, chore: add ci helper, and ci: restore.

• Check changes to GitHub Actions workflows, shell scripts, and package.json files.
• Verify whether a malicious payload ran in the affected repository or whether gaps appeared in the workflow-run history.
• If execution occurred, rotate the affected tokens, secrets, and cloud permissions.
• Check changes in AWS and Azure environments that could be related to persistence.
• Inspect developer devices if they may have run npm install on a compromised commit.

Some activity used tokens issued to the Fly.io GitHub App, but StepSecurity found no evidence that Fly.io infrastructure was compromised. Likewise, it has not been confirmed that the same actor responsible for the October GhostAction campaign is behind this activity; Aikido noted differences in the infrastructure and techniques used.

Further developments will show how GitHub, Fly.io, and other affected providers respond to the source of the compromised tokens, as well as whether any confirmed misuse of stolen credentials or malicious package releases emerges.

Verified and updated: November 12, 2026 15:23