Stolen credentials for 4,837 GitHub accounts enabled an attacker to deploy malware targeting repository secrets and cloud access, Aikido Security said in findings reported by The Hacker News on November 12. The campaign began Tuesday, November 10, and the malware executed in at least 1,806 repositories, where Aikido believes credentials were likely stolen.
Repository owners, organization administrators and developers who installed affected code face different exposures. Aikido considers any account used to open the attacker’s test pull requests compromised, whether or not malware subsequently ran. Where execution occurred, all secrets and cloud roles accessible to the automated workflows should be treated as compromised.
Write-access probes reached 61,764 repositories
The attacker checked each account’s repository permissions by submitting a pull request—a proposed code change—with the title docs: dependency audit notes from a wfx-docs branch. Aikido recorded these probes across 61,764 repositories. Collaborator or organization permissions accounted for 10,431 test pull requests, extending the campaign beyond repositories owned by the stolen accounts; 92% of those requests remained open when checked.
Most probed repositories either received no subsequent payload or had settings or account permissions that prevented execution. Aikido’s visibility was limited to public repositories, although private-repository settings in the malware suggested it might also be operating privately.
SafeDep, a software supply chain security company, separately identified malicious commits in 8,093 repositories between 12:46 UTC on November 10 and 04:36 UTC on November 12. This measures delivery, not execution. Its search examined only public repositories’ default branches, leading the researchers to assess that the total was higher.
Existing continuous integration (CI) workflows—automated jobs that build and check code—received the payload in 7,309 repositories. Another 771 received it through an npm postinstall hook, a script triggered by npm install that can also execute on a developer’s computer.
The activity continued beyond Aikido’s search, which ended Wednesday. The Hacker News checked three additional pull requests opened between 05:04 and 05:38 UTC on November 12: each used the same title and a wfx-docs branch, though subsequent malware delivery was unclear.
What the malware can take and retain
Aikido described a stealer designed to search the runner, the machine executing a workflow, for credentials. Its targets include GitHub Actions secrets and variables, GITHUB_TOKEN, Actions runtime tokens, AI service keys and secrets held in process memory. It also reads credential files used by AWS, Azure, GCP, Kubernetes, npm, PyPI, SSH and other tools.
The collection extends to repository contents, the latest 100 commits and recent workflow artifacts, or saved job outputs. On self-hosted runners, the malware additionally targets cloud credentials exposed through instance metadata, Docker container state and systemd units, which define system services.
SafeDep found two routes for sending stolen material out: HTTP POST requests to attacker servers and messages to a Telegram chat. Around one-fifth of 200 sampled payload commits relied exclusively on Telegram.
Cloud access can persist beyond replacement of the original secrets. The malware can exchange GitHub OpenID Connect (OIDC) tokens—identity assertions used by workflows to request cloud access—for sessions in AWS, GCP and Azure. Its AWS capabilities include creating long-lived access keys for Identity and Access Management users and changing a role’s trust policy to admit any AWS account.
For Azure AD applications, it can create federated identity credentials beginning wfx-ci-. These establish a trusted sign-in relationship, allowing workflows in the compromised repository to authenticate without a stored secret even after token rotation.
Aikido also found a connection to October’s GhostAction campaign, which used stolen GitHub accounts to introduce secret-stealing workflows. Accounts affected then were about 1,000 times more likely than other active accounts to appear in November’s activity. In more than 100 repositories, the latest payload entered October’s workflow files without removing their existing data-theft step. Aikido withheld attribution to the same actor because the infrastructure, tools and methods differed, and stolen credentials can circulate among multiple attackers.
Package exposure depends on how code is used
Automated publishing triggers carried the malware into at least one Packagist package and one Go module. At least 50 compromised users appear to publish through npm, Go, Packagist, PyPI or crates, although Aikido assessed that obtaining CI secrets was the attacker’s apparent objective.
The malicious Packagist release is digitalelvis/neuronai-studio version 3.14.3. Its listing showed a November 11 publication date; early November 12, it remained available beneath a notice that package versions had been flagged as malware. Aikido advises treating computers that installed or opened it as compromised. Execution depends on the command: ordinary composer install does not launch the stealer, whereas npm install inside the package’s vendor directory does. Users should block v3.14.3 and pin v3.14.2 or earlier.
For github.com/onuragtas/docker-env, versions v1.0.278 and v1.0.280 contain the payload solely in a GitHub Actions workflow. Neither the Go code nor release binaries changed, and Go builds do not execute workflow files, so module users may have escaped exposure. Aikido nevertheless recommends removing both versions.
Researchers also identified a malicious workflow in github.com/vkuznet/gocurl pseudo-version v0.0.0-20261111095532-8d5aad0cb0da. That workflow has never run; users should block the pseudo-version.
Commits attributed to wdio-bot brought the stealer into 28 WebdriverIO repositories. Package releases were unaffected, but the bot’s token should be considered stolen.
Find the changes, then revoke access
Repository owners should examine activity from November 10 onward in every repository they can write to. The attacker generally undid malicious changes within minutes and erased execution logs, usually deleting the workflow run too. A clean current file therefore does not settle whether credentials were exposed.
Look for branches named wfx-docs, short-lived branches matching chore/[a-z0-9]{8}, and branches matching ci-check-[0-9]{4}. Alongside the pull request title docs: dependency audit notes, these commit messages identify relevant changes:
ci: refresh build cache: approximately 1,500 lines inserted into an existing workflow.chore: add ci helper: a.ci-xxxxxx.shscript paired with a postinstall hook inpackage.json, triggered by anynpm install.chore: add dependency audit workflow: a new.github/workflows/build-audit-xxxxxx.ymlfile on achore/branch.chore: initial commit: a commit preceding the addition of a workflow file in an empty repository.ci: restoreandci: cleanup.
The stealer script’s SHA-256 fingerprint is 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf. Network indicators are 194.150.166[.]244:8080/exfil, 18.143.168[.]96:8080/exfil and 153.75.82[.]159:8080.
Missing wfx-loot artifacts, wfx- cache entries or WFX-BEGIN step summaries do not rule out theft. The researchers described a gap in run numbering on the attacker’s commit as a more reliable execution clue.
Cloud administrators should also check for the persistence mechanisms the researchers identified:
- Entra ID: unfamiliar federated credentials named
wfx-ci-*. - AWS CloudTrail:
AssumeRoleWithWebIdentityorAssumeRolesessions namedwfx-*, followed byCreateAccessKeyorUpdateAssumeRolePolicy. - GCP:
GenerateAccessTokenandSignJwtcalls originating from the GitHub workload identity pool, which provides workflow identities for cloud access. - Vault: JSON Web Token (JWT) logins using the GitHub OIDC issuer.
SafeDep advises owners of affected repositories to revoke the commit author’s tokens, OAuth application grants, SSH keys and sessions, enable two-factor authentication, and rotate every secret and variable readable by the repository. Developers who ran npm install against an affected commit should treat their computer as compromised and rotate its keys.
