Aikido and StepSecurity Say Stolen GitHub Credentials Have Been Used Since November 10 to Push the wfx CI Secret Stealer; Their Counts Differ

Overview

Security firm Aikido Security says that starting on November 10 a threat actor used stolen GitHub credentials to push a malicious workflow payload into tens of thousands of repositories, and it tracks the campaign as wfx-loot. StepSecurity, which calls it “WFX Phantom”, describes the same activity and says the attacker “does not exploit a bug in GitHub Actions” but has “valid tokens for real developer and bot accounts”. Both posts are dated November 12, 2026. The Hacker News and Help Net Security, the two independent outlets cited here, also reported the findings. The counts below are the sources’ own, taken at different times, and do not all agree.

What the sources counted

• Probe pull requests: Aikido says 4,837 compromised accounts opened probe pull requests in 61,764 repositories, and that 10,431 of the pull requests went into repositories the account does not own, reached through collaborator or organisation access. StepSecurity says that as of 07:40 UTC on November 12, GitHub search returned more than 63,000 of them.
• Share still open: Aikido writes that “92% of them are still open”, placing the figure after the 10,431 count, and The Hacker News reads it the same way. Help Net Security words it as “Ninety-two percent of the probe pull requests”, and StepSecurity says “about 90% of them still open” for its larger count.
• Repositories where the payload ran: Aikido’s text says it has “indications that the payload ran in at least 1,806 repositories” and that this “may understate impact”, while a summary bullet on the same page says “At least 1,835 repositories ran the payload”. The page does not explain the difference, and the Herald has not reconciled the two.
• Repositories with malicious commits: The Hacker News reports that SafeDep, which sells software supply chain security tools, counted 8,093 repositories between 12:46 UTC on Tuesday (November 10) and 04:36 UTC “today” (the article is dated November 12), covering only default branches of public repositories. In 7,309 of them the stealer was added to an existing workflow, and in 771 it came as an npm postinstall hook.

These figures count different things at different times, so they should not be added or compared directly.

How the payload is delivered

For each repository a stolen token can write to, Aikido says the attacker opens a pull request titled “docs: dependency audit notes” from a wfx-docs branch, which confirms write access, then pushes a shell script of about 1,500 lines in one of three ways: added to an existing workflow, as a hidden script run by a package.json postinstall hook, or in a new workflow on a throwaway branch. StepSecurity counts a fourth hiding place, the script appended to an existing shell script that a workflow already runs, such as update.sh in nextcloud/docker.

The sources differ on cleanup. Aikido says the actor “reverts within at most one minute and deletes the workflow run, along with its logs”; StepSecurity says “usually within a minute”, but describes a Nextcloud run that survived until a developer reverted the commit 27 minutes later. A correction on The Hacker News’s article says a second analysis found “changes left in place for longer”.

What it takes and what survives rotation

Aikido says the script collects GitHub Actions secrets and variables, the workflow’s GITHUB_TOKEN, OIDC and Actions runtime tokens, cloud and developer-tool credential files, and credentials for AI providers, among other items. It also lists steps meant to outlast credential rotation: rewriting an AWS role’s trust policy to "Principal": {"AWS": "*"}, which opens the role to any AWS account, and adding Azure federated identity credentials named wfx-ci-… that let workflows in the compromised repository sign in without a stored secret.

The sources differ on forged status checks. Aikido lists forged success status checks that clear merge gates among the payload’s actions, and Help Net Security states that the malware “forges passing status checks to clear branch protection”. StepSecurity calls the feature “built in, not used yet” and says “None of the 101 copies we examined had this turned on”.

Where stolen data goes also changed, according to StepSecurity’s samples. Aikido says the payload “was configured to send data only by HTTP POST” to 194.150.166[.]244:8080/exfil or 18.143.168[.]96:8080/exfil. StepSecurity dates the first sampled copies using those servers to November 10, the first copy with a third server and a Telegram backup to 01:10 UTC on November 12, and Telegram-only copies to about 05:30 UTC that day, so blocklists built from the November 10 addresses miss the newest copies.

Packages and bot accounts

Aikido names Packagist package digitalelvis/neuronai-studio version 3.14.3 and Go module github.com/onuragtas/docker-env versions v1.0.278 and v1.0.280. For the Go tags it says the payload is in a workflow file only, that “Go builds never run workflow files” and that consumers “may not have been affected”. The Hacker News adds that the Packagist listing shows version 3.14.3 was published on Wednesday (November 11) and that a normal composer install does not run the stealer but npm install inside the package’s vendor directory does. StepSecurity and The Hacker News both report that the stealer reached 28 WebdriverIO repositories through the project’s bot account wdio-bot, with no package release affected.

What is not established

• How the credentials were obtained. The Hacker News says Aikido’s analysis “does not explain” this, and StepSecurity says “We have not established how the tokens were obtained”. StepSecurity reports that 173 probe pull requests from 19 accounts were made through the Fly.io GitHub App (app ID 34557), and says it has “no evidence of a breach of Fly.io’s own infrastructure” and that most of the campaign’s activity used other credentials, such as personal access tokens. None of the four cited sources reports a statement from GitHub or Fly.io.
• Who is behind it. Aikido says accounts hit by October’s GhostAction wave were significantly more likely to be hit by wfx-loot, and The Hacker News reports they were “about 1,000 times more likely than other active accounts” to be used this week. Aikido assesses the campaigns as distinct and likely run by different actors, and StepSecurity says “Neither overlap proves a single actor”. The Herald previously reported on StepSecurity’s account of the earlier wave.
• Private repositories. Aikido says the payload’s private-repository settings suggest it “may be being deployed in private repositories” too.
• Whether it has stopped. StepSecurity said new probe pull requests were appearing every few minutes at 07:40 UTC on November 12. The Hacker News found three opened between 05:04 and 05:38 UTC from wfx-docs branches and says it is not clear whether the stealer followed.

What the sources advise

Aikido says that if the payload ran, every secret and cloud role available to the repository’s workflows should be assumed compromised. Help Net Security reports that the AWS trust-policy and Azure credential changes survive secret rotation and have to be removed in each affected cloud account.