'wfx-loot': 4,800 Hijacked GitHub Accounts Probed 61,764 Repositories and Planted a CI Secret Stealer That Reads Runner Memory and Deletes Its Tracks

DevSecOps · 2026-11-13 · By H.A

'wfx-loot': 4,800 Hijacked GitHub Accounts Probed 61,764 Repositories and Planted a CI Secret Stealer That Reads Runner Memory and Deletes Its Tracks

A campaign that began on 10 November uses stolen developer and bot tokens to inject a secret stealer into GitHub Actions workflows, CI scripts and npm hooks, with signs it ran in more than 1,800 repositories.

What Happened

A new campaign using stolen GitHub credentials has probed more than 61,000 repositories for write access. It has planted a CI secret stealer in workflows, build scripts and package install hooks. Researchers say the activity began on 10 November 2026 and used about 4,800 compromised developer and bot accounts to open probe pull requests against 61,764 repositories.

Researchers have named it "wfx-loot", and other teams call the stealer "wfx-phantom". This is a different operation from the Gheist token-abuse campaign reported last week. Researchers say it is more aggressive: instead of printing secrets into Actions logs, it plants malware that reaches into runner memory and cloud accounts. They see similarities with October's GhostAction campaign but believe the two are probably run by different actors.

How Far It Got

The figures differ depending on what is measured:

Affected releases include at least one Packagist (PHP) package and versions of two Go modules. That extends the risk from CI systems to developers who pulled those dependencies.

Technical Details

The attackers didn't exploit a bug in GitHub or GitHub Actions. They used valid tokens belonging to real developer and bot accounts. The method:

  1. Probe: open small pull requests or pushes to check whether a stolen token can change a repository.
  2. Plant: where permissions allow, inject the stealer into an existing or new GitHub Actions workflow, a shell script run by CI, or an npm install hook (preinstall/postinstall).
  3. Harvest: when the code runs, collect GitHub tokens, repository secrets, cloud credentials and AI service API keys. The stealer also reads the memory of the Actions runner process to get secrets that are masked in logs.
  4. Expand: use stolen cloud credentials to gain more access and establish persistence in AWS and Azure.
  5. Hide: revert the code changes and delete the workflow runs, so a quick look at the repository shows nothing wrong.

Researchers traced 173 of the probe pull requests to tokens issued to the Fly.io GitHub app. They could not tell how those tokens were obtained and found no evidence of a breach of Fly.io's infrastructure. Other tokens probably came from infostealer infections and earlier supply-chain incidents, which is how the previous token campaigns were fed.

Who Is Affected

What To Do Now

If the malware ran in any repository you own, assume every secret that workflow could reach is compromised.

A quick audit-log query with the GitHub CLI:

gh api -X GET "/orgs/YOUR_ORG/audit-log" \
  -f phrase="action:workflows.delete_workflow_run created:>=2026-11-10" \
  --paginate | jq -r '.[] | [.created_at, .actor, .repo] | @tsv'

To set the default token permission to read-only for an organisation:

gh api -X PUT /orgs/YOUR_ORG/actions/permissions/workflow \
  -f default_workflow_permissions=read

Why It Matters

This is the third large GitHub token-abuse campaign in about two months, and each one has spread wider. The pattern is clear: infostealers and earlier supply-chain breaches have created a large supply of valid developer tokens, and attackers now abuse them at industrial scale. No platform bug is needed. Over-permissive tokens, secrets available to every workflow and unreviewed changes to CI files are enough. Teams that treat their CI configuration as production infrastructure, with least-privilege tokens, short-lived credentials and mandatory review, are the ones this campaign could not reach.

REEF SENTINEL