A threat actor has used stolen GitHub credentials to push a secret-stealing payload into tens of thousands of code repositories.
The activity began on November 10, 2026, around 12:45 UTC. It aims at the secrets and cloud keys that sit inside GitHub Actions, the tool many teams use to build and ship code.
So far, 4,837 hijacked accounts opened probe pull requests in 61,764 repositories. At least 1,806 repositories ran the payload and lost credentials.
At least 50 of the hijacked users also publish packages for npm, Go, Packagist, PyPI or crates, which raises the risk for people who rely on their work.
Researchers at Aikido identified the malware and noted that the attacker seems to want CI secrets, not a wide supply chain spread. Still, the payload reached one Packagist package and one Go module through automated publishing triggers.
Hackers Hijack 4,837 GitHub Accounts
The attacker uses a stolen GitHub token to work on every repository that the token can write to. The first step is a probe. The attacker opens a pull request titled “docs: dependency audit notes” from a branch named wfx-docs, which proves the account has write access.
GitHub search shows 61,839 of these pull requests, opened between November 10 and November 11. Of these, 10,431 went into repositories the account does not own, reached through collaborator or organisation access.
About 92% are still open, so most owners have not noticed. If the probe runs, Aikido treats that user as compromised, even when the later workflow stage never runs. The second step pushes the real payload in one of three ways.
One way adds about 1,500 lines to an existing workflow. Another adds a hidden script and a postinstall hook in package.json, which runs on any npm install. The third creates a throwaway branch with a new workflow file.
The last step is cleanup. The attacker reverts the change within a minute and deletes the workflow run and its logs. A missing run number in the workflow history is often the only trace. This is why the 1,806 figure may be too low.
The overlap with earlier activity is notable. Many of these accounts were also hit in October, and the GhostAction GitHub account compromise reported earlier used a similar fake workflow trick.
Accounts hit in October were about a thousand times more likely than other active accounts to be used in November. In more than 100 repositories, the new payload was added to the old October workflow files.
Aikido does not link the two waves to one actor, because the tools, servers and methods differ, and stolen credentials often pass between groups.
What the Malware Steals and How to Respond
The payload is one shell script of about 1,500 lines. It is heavily commented and not hidden, and it calls itself “wfx”. It works in four stages: collect, escalate, persist and exfiltrate.
It first gathers GitHub Actions secrets, runtime tokens, cloud credential files, shell histories, and keys for AI tools such as OpenAI, Anthropic and Hugging Face. It also reads the memory of running processes to pull out tokens.
Next, it tries to go deeper into the cloud. It swaps GitHub OIDC tokens for AWS, Google Cloud and Azure sessions. In AWS, it creates long-lived access keys.
The script then tries to survive a password reset. It forges “success” status checks to get past branch protection, rewrites an AWS role so any account can use it, and adds new federated identity credentials in Azure.
This is similar to the pattern seen in the Shai-Hulud npm supply chain worm, where postinstall hooks and workflow files also took secrets.
In this campaign, the stolen data goes out only by HTTP POST to two servers. Other exfiltration channels in the script were turned off, such as cache entries, artifacts and encrypted commits.
Because of this, finding no “wfx-loot” artifacts does not prove your data is safe. Aikido says a missing run number on the attacker’s commit is the better sign that the payload ran.
Defenders should first search for the branches, pull request titles and commit messages listed below. If the payload ran, assume every secret and cloud role available to the workflow is exposed, and rotate them all.
Revoke the hijacked GitHub tokens, and review audit logs for new federated credentials and changed AWS trust policies. Teams should also use phishing-resistant sign-in, limit workflow permissions and watch outbound traffic from runners.
These steps match the advice from the earlier 790 GitHub repositories hijacked report, and the lessons from the tj-actions supply chain attack still apply.
Treat the Packagist package digitalelvis/neuronai-studio 3.14.3 as hostile, and treat any machine that installed or opened it as compromised. The Go module versions carry the payload only in a workflow file, so users may not be affected, but Aikido still advises removing them.
Indicators of compromise (IoCs):-
| Type | Indicator | Notes |
|---|---|---|
| Packagist package | digitalelvis/neuronai-studio 3.14.3 | Malicious version |
| Go module | github.com/onuragtas/docker-env v1.0.278, v1.0.280 | Payload in a workflow file only |
| Network | 194.150.166[.]244:8080 (/exfil) | Exfiltration server |
| Network | 18.143.168[.]96:8080 (/exfil) | Exfiltration server |
| GitHub branches | wfx-docs, chore/[a-z0-9]{8}, ci-check-[0-9]{4} | Probe and payload branches |
| Pull request title | docs: dependency audit notes | Probe pull request |
| Commit messages | ci: refresh build cache; ci: restore; chore: add ci helper; ci: cleanup; chore: add dependency audit workflow | Payload and cleanup commits |
| SHA-256 | 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf | Stealer script |
Note: IP addresses and domains are intentionally Qdefanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Give your SOC the alert context on the latest threats to stop incidents quickly -> Integrate Threat Intel from 16K SOCs

