November 12, 2026 – An automated supply chain attack is sweeping through GitHub, using thousands of hijacked developer accounts to plant secret-stealing code in build pipelines. Security firms including Aikido Security, StepSecurity and SafeDep say the attacker tested stolen write access across more than 60,000 repositories and ran a credential stealer in at least 1,800 of them.

Aikido tracks the campaign as wfx-loot, after the malware’s self-assigned “wfx” name and its label for stolen data. It began on November 10. The attacker did not exploit a flaw in GitHub or GitHub Actions. Instead, they used valid tokens belonging to real developers and bots, likely stolen earlier. Aikido found that accounts hit by the October GhostAction campaign were significantly more likely to be affected, and in more than 100 repositories wfx-loot was injected into GhostAction’s own workflow files.

How the attack works

1. Probing. 4,837 compromised accounts opened probe pull requests across 61,764 repositories, often on a branch named wfx-docs and titled “docs: dependency audit notes.” The pull requests do nothing on their own. They test whether the stolen access allows changes.
2. Planting the payload. Where access was confirmed, the attacker added a roughly 1,500-line shell script. It was placed in existing or new GitHub Actions workflows, in shell scripts run by CI, or in npm install hooks. Commits commonly used the message “ci: refresh build cache.”
3. Covering tracks. The attacker reverted the malicious changes and deleted workflow runs, leaving little for maintainers to find afterward.

What it targets

The script hunts for GitHub tokens, repository secrets, cloud credentials and AI service keys. It can also read runner process memory and includes routines to expand access and persist in AWS and Azure environments. Aikido says some exfiltration features were switched off in this campaign, so confirmed execution does not necessarily mean data was taken.

Scale

Aikido found the stealer ran in more than 1,800 repositories. SafeDep separately counted 8,093 public repositories that received malicious commits, though that doesn’t mean every one executed the payload. Aikido also observed the campaign reaching published packages through automated publishing triggers, and says dedicated settings for private repositories suggest those may be targeted too. Figures are still changing, and some outlets report higher totals.

What to do

• Search your repositories for the wfx-docs branch, the “docs: dependency audit notes” pull request title, and “ci: refresh build cache” commits dating from November 10.
• Look for gaps in sequential workflow run numbers, which can indicate deleted runs.
• Don’t treat a clean result as proof of safety. Aikido warns that missing wfx-loot artifacts, wfx- cache entries or WFX-BEGIN step summaries doesn’t mean nothing was taken.
• If a collaborator’s account opened a probe pull request, even a closed one, revoke its personal access tokens, SSH keys and OAuth sessions.
• Treat every secret reachable by an affected repository’s runner as exposed. Rotate cloud keys, AI API keys and package-registry tokens, and review cloud audit logs for unfamiliar persistence.
• If you publish packages, check for releases you didn’t authorize since November 10.

Sources: Aikido Security, SecurityWeek, Cybernews