Press play to start listening
Hackers used 4,837 compromised GitHub accounts in the wfx-loot campaign to target repositories and steal developer credentials, cloud keys and tokens.
Hackers have used thousands of compromised GitHub accounts to target public repositories with credential-stealing code, with researchers confirming that the malware ran and stole secrets from at least 1,835 repositories.
Aikido Security identified the campaign as wfx-loot. Its initial findings counted 4,837 compromised accounts opening probe pull requests across 61,764 repositories. Subsequent research documented continued activity, changes to the malware and the exposure of some GitHub tokens through applications deployed on Fly.io.
The targeted-repository count does not mean every repository ran the malware. Many received only a probe, while execution depended on the stolen account’s permissions and the repository’s configuration.
Routine-looking pull requests tested stolen access
According to Aikido researcher Oliver Smith, the campaign began on November 10. Attackers opened pull requests titled docs: dependency audit notes from branches named wfx-docs to test whether stolen credentials could write to a repository.
The probe itself did not contain the credential stealer. Where access allowed, attackers followed it with malicious commits disguised as routine maintenance.
Aikido initially documented three delivery methods, including changes to existing GitHub Actions workflows, npm installation hooks and new workflows on temporary branches.
StepSecurity subsequently documented another method, inserting the payload into existing shell scripts that automated workflows already execute. These changes can leave the workflow file itself untouched.
Once executed, the roughly 1,500-line shell script searches for GitHub secrets, workflow tokens, cloud credentials, SSH and GPG keys, environment files, Kubernetes configurations and developer-tool credentials. It also targets credentials associated with AI services, including OpenAI, Anthropic and Google Gemini.
Attackers then revert their changes and delete workflow runs and logs, sometimes within a minute.
Fly.io confirms exposure of some GitHub tokens
In a November 12 security notice, Fly.io confirmed that an unauthorised party had used tokens issued to its GitHub App against customer repositories.
Its deployment process had left a GitHub access token in the build directory’s .git/config file. Some applications included that directory in their deployed images and served it publicly, allowing attackers to retrieve the file.
Fly.io confirmed misuse affecting a small number of accounts. It initiated revocation of every user token issued to its GitHub App, notified affected customers and changed the deployment process to prevent the exposure.
The company said its own systems were not breached. Deployments using flyctl and Fly.io API tokens were not affected.
The disclosure explains how attackers obtained some credentials used in wfx activity. It does not establish the source of every compromised account in the wider campaign.
New payloads use Telegram to send stolen data
The original samples sent stolen information to external collection servers. StepSecurity observed newer samples using only Telegram from approximately 05:30 UTC on November 12. Blocking the initially published collection IP addresses therefore does not stop these newer variants.
StepSecurity also documented malicious commits in nextcloud/docker and webdriverio/webdriverio, including execution in a Nextcloud workflow. It reported that no WebdriverIO package release was affected.
These findings establish activity in specific repositories, rather than a breach of every system operated by those organisations.
Repository access can lead to cloud access
The payload also attempts to use stolen credentials and GitHub’s OpenID Connect authentication to obtain access to connected cloud services.
Depending on the permissions and trust settings available, its capabilities include requesting cloud sessions, creating AWS access keys, changing AWS role trust policies and adding federated identity credentials to Azure applications. It also targets Google Cloud service accounts, Kubernetes and HashiCorp Vault.
These are capabilities of the script, not confirmed outcomes in every affected repository. The credentials and permissions available to each workflow determine how far an attacker can proceed.
Deleting the malicious code does not revoke credentials already stolen. Likewise, rotating an exposed secret does not remove a new access key or federated identity credential that an attacker has created.
Later research reports continued activity
In its November 12 report, OX Security counted more than 66,200 probe pull requests and malicious commits in 8,093 public repositories. More than 4,100 of the probes were opened on November 12.
Those figures measure separate stages of the attack. Probe pull requests, repositories receiving malicious commits and repositories where credentials were stolen should not be treated as interchangeable counts.
Aikido’s summary reports confirmed execution and credential theft in at least 1,835 repositories.
The campaign also reached published packages through automated release processes. Aikido identified malicious content in Packagist package digitalelvis/neuronai-studio version 3.14.3 and workflow files included in versions of the Go module github.com/onuragtas/docker-env.
For the Go versions described in Aikido’s report, the source code and release binaries were unchanged. Installing or compiling a Go module does not execute its GitHub Actions workflow files, so their presence does not establish that ordinary module consumers ran the stealer.
What affected teams should check
Repository owners should review activity since November 10 for unfamiliar wfx-docs branches, dependency-audit pull requests and commits presented as CI maintenance.
Checks should cover existing shell scripts and npm hooks as well as workflow files. Reverted changes and deleted runs also warrant investigation, because the current branch may no longer contain the payload.
Where the malware ran, teams should treat the secrets and cloud access available to that workflow as compromised. Recovery requires revoking exposed tokens, rotating credentials and checking connected cloud accounts for unauthorised access or persistence.
Aikido also found overlap with repositories previously affected by GhostAction, including more than 100 cases where wfx-loot was inserted into earlier malicious workflows. It assesses the campaigns as likely involving different actors.
The reported attack uses stolen credentials rather than exploiting a disclosed GitHub software vulnerability. For affected teams, recovery must address the compromised account, the repository’s automation and any external services those workflows could access.
