'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

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:

• 61,764 repositories received probe pull requests testing whether stolen access allowed changes.
• 8,093 public repositories received malicious commits, according to one research team. That doesn't necessarily mean the code ran.
• More than 1,800 repositories show signs the stealer actually ran, according to another team.

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

• Maintainers whose personal access tokens, OAuth app tokens or GitHub app installation tokens have leaked
• Organisations whose repositories had default write permissions for GITHUB_TOKEN or long-lived secrets available to every workflow
• Developers who installed affected package versions, since the install hooks run on their own machines
• Anyone who granted repository access to the Fly.io GitHub app should review its activity

What To Do Now

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

• Revoke and rotate: revoke suspicious tokens, rotate repository and organisation secrets, cloud keys and AI API keys, and review GitHub app installations.
• Search for probes: look for unexpected pull requests, branches or commits from accounts and bots around and after 10 November, even if they were reverted.
• Check the audit log: because the attackers delete workflow runs, rely on the organisation audit log, not the Actions tab. Look for workflows.delete_workflow_run events and pushes to .github/workflows/.
• Check the cloud: in AWS and Azure, look for new IAM users, access keys, roles, federated credentials or app registrations created since 10 November.
• Harden workflows: set the default GITHUB_TOKEN to read-only, require review for workflow file changes with CODEOWNERS and branch protection, use OIDC with tightly scoped trust policies instead of static cloud keys, and pin third-party actions to commit SHAs.

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.