Thousands of Hijacked GitHub Accounts Plant a Secret Stealer in CI Pipelines: What the wfx Campaign Means for Every Team That Builds Software

Since Tuesday 10 November 2026, an attacker has been working through thousands of stolen GitHub accounts to plant a credential stealer inside the build pipelines of other people's software. The target is not the code itself but the keys that sit around it: the secrets, tokens and cloud credentials that GitHub Actions uses every time a project is built, tested or deployed.

The malware, a shell script of around 1,500 lines that names itself wfx, was identified by Aikido Security. By the end of the first two days Aikido had counted 4,837 hijacked accounts opening probe pull requests in 61,764 repositories, and at least 1,806 repositories where the payload ran and credentials were lost. Later counts reported by Cybernews put the number of targeted repositories above 66,000. Some of the affected projects belong to well-known open source communities, government bodies and very large companies.

What Happened

According to Aikido's analysis, as reported by Cyber Security News, the activity began at around 12:45 UTC on 10 November. It runs in three steps, and each one is designed to be quiet.

First, the attacker uses a stolen token to open a harmless-looking pull request titled "docs: dependency audit notes" from a branch called wfx-docs. Nothing in it is malicious. Its only purpose is to confirm that the token can write to the repository. About one in six of these probes went to repositories the hijacked account did not own, reached through collaborator or organisation access, which shows how far a single developer's token can travel.

Second, where the token has enough permission, the attacker delivers the payload. The most common method is to append the script to an existing workflow under a commit titled "ci: refresh build cache". Other variants add a hidden helper script triggered from a package's install step, or create a throwaway branch with a new workflow file.

Third, the attacker cleans up. Within about a minute the change is reverted with commits such as "ci: restore" or "ci: cleanup", and the workflow run and its logs are deleted. In many cases a missing run number in the workflow history is the only trace left behind.

What the Stealer Does

Once it runs inside a build, wfx works in four stages. It collects GitHub Actions secrets, runtime tokens, cloud credential files, shell histories and API keys for AI services, including tokens pulled from the memory of running processes. It escalates by exchanging the workflow's GitHub OIDC token for AWS, Google Cloud and Azure sessions and creating long-lived AWS access keys. It persists by forging "success" status checks to get past branch protection, changing an AWS role so that any account can assume it, and adding federated credentials in Azure. Finally it sends everything out by HTTP to attacker-controlled servers, with newer versions reported to use Telegram instead.

Aikido's view is that the attacker wants CI secrets rather than a broad software supply chain infection, but the payload has still reached one Packagist package and one Go module through automated publishing. Aikido also found that accounts hit in an earlier wave in October were around a thousand times more likely than other active accounts to be reused in November, although it has not linked the two waves to a single actor.

Who Is Affected

Anyone whose GitHub account token was stolen is a potential entry point, and anyone whose repository that account could write to is a potential victim. Cybernews reported affected repositories belonging to Nextcloud, WebdriverIO, the US General Services Administration and France's beta.gouv.fr programme, and compromised accounts belonging to staff at Fortune 100 organisations. Researchers have stressed that a hijacked account does not prove the payload ran in every organisation that account belongs to, and private repositories can be affected as well as public ones.

The packages flagged so far are version 3.14.3 of digitalelvis/neuronai-studio on Packagist, which should be treated as malicious, and versions 1.0.278 and 1.0.280 of the Go module github.com/onuragtas/docker-env, which carry the payload in a workflow file. At least 50 of the hijacked users also publish packages to npm, Go, Packagist, PyPI or crates, so the list may grow.

At the time of the reports we reviewed, about 92 per cent of the probe pull requests were still open, which means many maintainers have not yet noticed them.

Why It Matters

For many organisations, the build pipeline is the most privileged system they have and the least watched. It holds deployment keys, signing keys and cloud roles, and it is trusted to change production. This campaign shows three things.

The first is that a stolen developer token is now an attack on everyone that developer can push to. The probe step proves write access across personal projects, employers' organisations and open source collaborations in one sweep.

The second is that cleanup has become part of the attack. Reverting within a minute and deleting run logs means that a quick look at the repository the next morning shows nothing. Detection has to rely on audit logs, run number gaps and outbound network monitoring rather than on the code itself.

The third is that cloud federation cuts both ways. Short-lived OIDC credentials are a real improvement on stored secrets, but a workflow that can mint broad cloud sessions is still a workflow an attacker can use. Trust policies need to be scoped to specific repositories, branches and environments, not to any workflow that asks.

What To Do Now

Search for the campaign's fingerprints. Look across your organisation's repositories for pull requests titled "docs: dependency audit notes", branches named wfx-docs, chore/ followed by eight characters or ci-check- followed by four digits, and commits titled "ci: refresh build cache", "ci: restore", "ci: cleanup", "chore: add ci helper" or "chore: add dependency audit workflow". Close and investigate any you find.

Check for missing workflow runs. A gap in a workflow's run numbers around 10 November or later may mean a run was deleted. Treat it as evidence that the payload executed.

If it ran, rotate everything it could reach. That means every secret available to the workflow, every cloud role it could assume and every token in the environment, not just the GitHub token. Revoke the hijacked account's tokens and sessions.

Review your cloud audit logs. Look for new long-lived AWS access keys, changed role trust policies, new federated identity credentials in Azure and unexpected service account activity in Google Cloud.

Check branch protection and status checks. The payload forges successful checks. Make sure required checks come from the apps you expect and that changes to workflow files need review.

Remove the affected packages. Remove digitalelvis/neuronai-studio 3.14.3 and treat any machine that installed or opened it as compromised. Remove the affected docker-env module versions.

Reduce the blast radius for next time. Enforce phishing-resistant sign-in for GitHub, set default workflow permissions to read-only, scope OIDC trust to named repositories and branches, and monitor outbound connections from build runners. Our article on preventing supply chain attacks covers the wider principles.

How Cybergen Can Help

Cybergen's DevSecOps and code security work helps teams lock down CI/CD permissions, secrets and cloud trust relationships. If you believe a pipeline has been compromised, our incident response service can help you scope what was exposed and rotate it in the right order.

Frequently Asked Questions