Have you checked your GitHub repositories for this CI secret stealer?

What The Hacker News, citing security researchers, describes

An attacker used stolen credentials for 4,837 GitHub accounts to plant a secret stealer in repositories those accounts could write to. Each attack started with a pull request titled docs: dependency audit notes, opened from a branch named wfx-docs, to test whether the account could write to the repository. Those probe pull requests were opened in 61,764 repositories, and the stealer followed in some of them. The report says any account that opened one of those probe pull requests is compromised, even if the stealer never ran. The analysis, as reported, does not explain how the attacker obtained the credentials.

The stealer ran in at least 1,806 repositories, where the attacker has likely collected credentials. In a separate count in the same report, 8,093 repositories received malicious commits between 12:46 GMT on 10 November and 04:36 GMT on 12 November 2026. That count covers every repository that received malicious commits, not only those where the stealer ran, and only the default branches of public repositories, so the true total is higher. In 7,309 of those repositories, the stealer was added to an existing workflow. In 771, it came as an npm postinstall hook, which also runs on a developer's machine during npm install. After pushing the stealer, the attacker usually reverted the change within minutes. Where the stealer ran, its logs were deleted, usually along with the run itself. In those repositories, every secret and cloud role available to the workflows should be treated as compromised.

Of the probe pull requests, 10,431 were submitted via collaborator or organisation access, and 92% of those were still open when the researchers checked. In most other repositories that received a test, nothing was pushed afterward, or the stealer did not run because of the repository's settings or the account's permissions. The figures cover only the public repositories the researchers could see.

What the stealer is reported to take, and what can survive rotation

The stealer is built to collect credentials from sources on the runner, according to the report. They include GitHub Actions secrets and variables, the workflow's GITHUB_TOKEN, OIDC and Actions runtime tokens, keys for AI services, and secrets in the memory of the runner's own processes. It reads credential files for AWS, Azure, GCP, Kubernetes, npm, PyPI, SSH and other tools from their usual locations. It also copies the repository, its last 100 commits, and recent workflow artefacts. On self-hosted runners, it takes cloud credentials from instance metadata, as well as Docker container state and systemd units. The report says the stealer has settings for private repositories, which suggests it may be running in them.

It is designed to use those credentials to reach further into cloud accounts. It exchanges GitHub OIDC tokens for AWS, GCP and Azure sessions, and on AWS it can create long-lived access keys for IAM users. Some of its steps are built to survive credential rotation. It can rewrite an AWS role's trust policy so the role can be assumed from any AWS account. It can also add federated identity credentials with the prefix wfx-ci- to Entra ID (Azure AD) applications, so workflows in the compromised repository can sign in to Azure without a stored secret, even after tokens are rotated.

Packages named in the report

The Hacker News, citing security researchers, says the stealer reached at least one Packagist package and one Go module through automated publishing triggers. At least 50 of the compromised users appear to publish packages for npm, Go, Packagist, PyPI or crates. The attacker appears to be after CI secrets rather than trying to spread through packages.

The report describes version 3.14.3 of the Packagist package digitalelvis/neuronai-studio as malicious, and says to treat any machine that installed or opened it as compromised, and to block v3.14.3. The same report had advised a pin that included 3.14.2. We have updated that pin in the our-findings section below. A normal composer install does not run the stealer, but running npm install inside the package's vendor directory does, the researchers found. The report says v3.14.3 was published on Wednesday 11 November 2026. Two versions of the Go module github.com/onuragtas/docker-env, v1.0.278 and v1.0.280, carry the stealer only in a GitHub Actions workflow file. The report says the Go code and release binaries are unchanged, and that Go builds never run workflow files, so users of the module may not have been affected. The researchers still recommend removing those versions. The stealer was also found in github.com/vkuznet/gocurl, in pseudo-version v0.0.0-20261111095532-8d5aad0cb0da, inside a workflow that has never run. Users should block that pseudo-version. The stealer also reached 28 WebdriverIO repositories through commits authored as the bot account wdio-bot. No package release was affected, but the report says the bot's token should be treated as stolen.

Our package findings (checked at 09:42 GMT on 12 November 2026)

These are our findings, not The Hacker News. We checked Packagist and the Go module proxy (proxy.golang.org), then inspected the published archives for the known indicators (helper scripts, workflow content, exfiltration hosts, wfx markers and Telegram delivery). We did not run any of the packages.

digitalelvis/neuronai-studio 3.14.4 was published at 07:50 GMT on 12 November 2026 and was still downloadable when we checked. It carries the stealer: a .ci-uxe0r4.sh helper and a package.json postinstall hook, with the campaign's wfx markers and Telegram delivery. When we checked, Packagist's malware list flagged 3.14.2 and 3.14.3, but not 3.14.4. Because 3.14.2 is on that list (it is an October release), the safe pin is 3.14.1 or earlier, not 3.14.2. Block 3.14.3 and 3.14.4 as well, and treat any machine that installed or opened 3.14.3 or 3.14.4 as compromised.

github.com/onuragtas/docker-env and github.com/onuragtas/redock v1.0.282, published at 05:19 GMT on 12 November 2026, and v1.0.284, published at 08:59 GMT the same day, carry the stealer in a GitHub Actions workflow file, in a Telegram variant. Go builds do not run workflow files, but we still recommend removing those versions, as the report does for v1.0.278 and v1.0.280. The Go module proxy shows that each redock version we name here points at the same revision as the matching docker-env version. A later version, v1.0.285, was published at 09:00 GMT; we did not find the known stealer indicators in that archive, and we do not list it as a poisoned release.

Overlap with an earlier October campaign

The report says the accounts used this week overlap with those hit in GhostAction's October wave, in which stolen GitHub accounts pushed secret-stealing workflows into repositories. Accounts hit in October were about 1,000 times more likely than other active accounts to be used this week. In more than 100 repositories, the new stealer was added to October's workflow files, leaving the older step that sends data out in place.

Reported signs and indicators

The Hacker News, citing security researchers, lists these signs from Tuesday, 10 November 2026 onwards, in any repository you can write to. We have not independently confirmed them in a customer environment. Hosts and addresses are written in defanged form and are not links. Branches: wfx-docs; short-lived branches matching chore/[a-z0-9]{8}; branches matching ci-check-[0-9]{4}. Pull request title: docs: dependency audit notes. Commit messages: ci: refresh build cache (adds a large block to an existing workflow); chore: add ci helper (adds a .ci-xxxxxx.sh script and a postinstall hook in package.json); chore: add dependency audit workflow (adds .github/workflows/build-audit-xxxxxx.yml on a chore/ branch); chore: initial commit, pushed before a new workflow file in an empty repository; ci: restore; and ci: cleanup. SHA-256 of the stealer script, as reported: 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf. Exfiltration addresses, as reported: 194.150.166[.]244:8080/exfil, 18.143.168[.]96:8080/exfil, and 153.75.82[.]159:8080. The report also says data was sent to a Telegram chat; no chat identifier is given. A repository can show no wfx-loot artefacts, wfx- cache entries or WFX-BEGIN step summaries and still have lost data. A missing run number on the attacker's commit is described as the more reliable sign that the stealer ran. For persistence, the researchers suggest checking Entra ID for federated credentials named wfx-ci-* that you did not create; AWS CloudTrail for AssumeRoleWithWebIdentity or AssumeRole sessions named wfx-*, followed by CreateAccessKey or UpdateAssumeRolePolicy; GCP GenerateAccessToken and SignJwt calls from your GitHub workload identity pool; and Vault JWT logins from the GitHub OIDC issuer.

If you find signs of compromise (our advice)

• Isolate the affected repository and any runner or developer machine that may have executed the stealer or an npm postinstall hook, and preserve evidence before cleanup.
• Revoke the compromised GitHub account's tokens, OAuth app grants, SSH keys and sessions from a trusted device, turn on two-factor authentication, and rotate every secret and variable the repository can read, plus any cloud, registry or host keys those secrets could reach.
• Hunt for persistence that can survive rotation, including Entra ID federated credentials named wfx-ci-*, AWS role trust-policy changes and long-lived IAM keys, GCP token and signing calls, and Vault JWT logins from GitHub OIDC.
• Block or remove the named package versions, and treat the wdio-bot token as stolen.
• Start incident response for every cloud account, package registry and system those secrets could reach, not only the GitHub repository.
• CybaOps can help you hunt and contain across your estate and your clients' environments.