wfx-loot: The GitHub Attack That Steals CI Secrets and Covers Its Tracks

A supply-chain campaign known as wfx-loot is using stolen GitHub credentials to plant a secret-stealing script in repositories those accounts can write to. The script runs inside GitHub Actions and, on developer machines, through npm install hooks. It collects cloud keys, package-registry tokens, GitHub tokens and AI API keys, sends them out, then removes the commit and the workflow evidence so the repository looks untouched.

By 12 November 2026 the operators had used 4,837 hijacked GitHub accounts, opened more than 66,200 probe pull requests, pushed a malicious commit into 8,093 public repositories, and taken secrets from at least 1,806 of them. More than 4,100 new probe pull requests went out on 12 November alone, and the counts were still rising that day. Public totals leave out private repositories and work on non-default branches, so more projects may be affected. If you run GitHub Actions, Composer or npm — the kind of pipeline we build at DayDecoder, a custom software company in Ahmedabad — this is worth checking today.

What happened

This is not a break of GitHub as a platform. The malicious commits are authored as the real users of each repository, with those users' GitHub noreply addresses and no commit signature — the fingerprint of stolen access tokens. At least 50 of the 4,837 hijacked accounts publish packages to npm, Go, Packagist, PyPI or crates.io. 10,431 probe pull requests targeted repositories the hijacked account does not own, through collaborator, organisation or bot access, including 28 WebdriverIO repositories reached through that project's bot account.

Stolen data first went to attacker-controlled HTTP servers. From about 05:30 UTC on 12 November 2026, newer copies started sending it through five Telegram bots. The stealer is one shell script, about 1,500 lines long, with no real obfuscation. It only needs to sit on the default branch long enough for a workflow or an npm install to run.

How the attack works

The attack follows four steps. First, a probe pull request titled docs: dependency audit notes is opened from a branch named wfx-docs, to confirm write access. Second, a commit disguised as CI maintenance — titled ci: refresh build cache, chore: add ci helper or chore: add dependency audit workflow — plants the stealer in an existing workflow, a new workflow file, an existing shell script, or an npm postinstall hook. Of the 8,093 public repositories hit on their default branch, 7,309 were through workflow injection, 771 through npm postinstall hooks, and 16 through new workflow files.

Third, the next GitHub Actions run or npm install executes the script and harvests GitHub tokens; AWS, Azure and GCP credentials; publishing tokens for npm, PyPI, Packagist and crates.io; Kubernetes and Vault secrets; and AI provider API keys. Fourth, within seconds or minutes, a ci: restore or ci: cleanup commit reverts the change and the workflow run and its logs are deleted.

On 11 November 2026 at 12:11 UTC, two chore: add ci helper commits were pushed to WebdriverIO through the project's bot account and bypassed branch protection. A contributor noticed, and they were reverted in about 20 minutes. A bot allowed to skip protection rules is as useful to an attacker as a stolen human token.

Signs to check in your organisation

Search back to 10 November 2026 for those pull request and commit titles, for branches named wfx-docs, and for gaps in GitHub Actions run numbers. Also look for Azure or Entra ID federated credentials named wfx-ci-*, AWS sessions named wfx-*, and AWS role trust policies that allow any principal. If you find the probe pull request, close or decline it, then revoke the tokens behind the account that opened it. A clean default branch is not proof that nothing ran. On 12 November 2026, around 89 percent of the probe pull requests — roughly 58,900 — were still open, and malicious payloads and package versions were still present.

Compromised packages to look for

If any of these versions appears in a lockfile, or was installed on a machine or CI runner, treat that environment as compromised, rotate its secrets, and move to the fixed version — or the previous clean release. Laravel teams should check Composer lockfiles for digitalelvis/neuronai-studio 3.14.3.

What developers and businesses should do now

1. Revoke GitHub tokens and rotate secrets — every repository and organisation secret, variable and cloud role that workflow could reach, even if no run is visible.
2. Hunt for persistence — the wfx-ci-* and wfx-* names above, and any AWS role trust policy that allows any principal — before you close the incident.
3. Move to short-lived credentials and use OIDC so GitHub Actions can assume a cloud role without a long-lived access key.
4. Pin GitHub Actions to a full commit SHA, not a moving tag such as @v4.
5. Give GITHUB_TOKEN the least privilege the job needs. Do not grant write access, or access to secrets from other workflows, by default.
6. In CI, install npm packages with --ignore-scripts unless a trusted package truly must run a lifecycle script.
7. Tighten branch protection with required reviews, no force-pushes and no administrator bypass on default branches, then review every bot and GitHub App allowed to skip those rules.
8. Upgrade any package in the table above and rotate. Copies of the Go modules may still sit in a module proxy cache.

How we approach CI/CD at DayDecoder

At DayDecoder we treat the pipeline as part of the product. On the Laravel, Node.js and mobile codebases we build, the practices above are the ones we apply. None of that makes an organisation immune. If you want a second pair of eyes on your GitHub Actions or Laravel deploy workflow, use the contact form. We reply within one business day.

FAQ

I only found the probe pull request. Is the account safe?

No. Treat that account as compromised, revoke its tokens, and review every repository it can access.

There is no workflow run in the Actions tab. Does that mean the stealer never ran?

Not necessarily. This campaign deletes the run and its logs. Check for a gap in run numbers, and rotate anyway if a malicious commit landed in a repository with GitHub Actions enabled.

Is this a breach of GitHub itself?

The evidence points to stolen user tokens, not a compromise of the GitHub platform.