The wfx-loot campaign shows that CI credential design fails when a stolen write token can change workflows and read what they reach. Aikido Security reported that, from November 10, 4,837 compromised accounts probed 61,764 repositories and the stealer ran in at least 1,835. For teams whose agents and bots share write access, short-lived OIDC was not the whole fix.
Updated November 12, 2026
Key Takeaways
- Aikido: 4,837 accounts probed 61,764 repositories from November 10.
- The stealer ran in at least 1,835 repositories and deleted workflow logs.
- Aikido: 92% of the 10,431 non-owned probes were still open.
- AWS trust rewrites and Azure federated credentials survive secret rotation.
What does a stolen write token change?
The probe pull request, titled docs: dependency audit notes and opened from wfx-docs, only confirms write access. Aikido said that if the probe ran, that user is compromised even if the workflow stage did not run. Of those pull requests, 10,431 went into repositories the account did not own, and Aikido said 92% of them are still open.
StepSecurity, as reported by SecurityWeek, said:
The attacker does not exploit a bug in GitHub Actions.
The intruder used valid developer and bot tokens. Cycode noted that closing a probe does not revoke the token.
SecurityWeek reported 173 probes tied to Fly.io GitHub app tokens and no evidence Fly.io’s infrastructure was breached. Cybernews reported those tokens let the attacker act as the connected user. Analysis: that app token is a distribution channel.
Why is short-lived OIDC not the whole fix?
Aikido’s payload description is the evidence. The script collects Actions secrets, the workflow token, and OIDC tokens, and it mints GitHub OIDC tokens for AWS, GCP, and Azure, then exchanges them for cloud sessions. It can also create long-lived AWS keys for IAM users it reaches. The same collection includes AI tool tokens, among them OpenAI, Anthropic, Cursor, and Copilot.
Rotation misses what the job writes. Aikido reported an AWS trust policy opened to any AWS account, and Azure federated credentials, named with a wfx-ci- prefix, pointed at the compromised repository. Help Net Security reported that those credentials let workflows in that repository sign in after every token has been rotated.
Analysis: OIDC still beats a static cloud key stored for an honest job, because that session expires. It does not beat a malicious job allowed to assume the same role, or a trust edit that remains after the GitHub token is revoked.
How do static secrets compare with OIDC and deploy keys?
Static Actions secrets are the wide dump. The injected step passes the full secrets context and variables into the job, and the script reads credential files, shell history, and runner memory. SSH key files on the runner are still collected, so keeping deploy keys out of Actions secrets is not the same as keeping them off the machine. The stolen write token still pushed the workflow, reverted it within a minute, and deleted the run.
The table is an analysis of those paths, not a new measurement.
| Pattern | During the run | After rotation |
|---|---|---|
| Static secrets | Full secrets context and runner files | Long-lived AWS keys created in the job |
| OIDC federation | Cloud sessions minted during the run | AWS trust edits and Azure federated credentials |
| Deploy keys outside Actions | Missing from the secrets context; files on the runner still readable | Stolen write token until it is revoked |
How should CI credential design change after a stolen PAT?
Publishers are a special blast radius. Aikido assesses a focus on CI secrets rather than supply-chain spread, yet automated publishing carried the payload into Packagist package digitalelvis/neuronai-studio 3.14.3 and into workflow files of Go module github.com/onuragtas/docker-env v1.0.278 and v1.0.280.
Go builds never run workflow files. Aikido limits the compromised-machine instruction to the Packagist package: treat any machine that installed or opened that package as compromised. At least 50 compromised users appear to publish packages, and an npm postinstall variant can run on a machine that installs the commit.
- Revoke PATs, SSH keys, and GitHub App or OAuth grants for every probe author, and replace stored bot tokens.
- Rotate workflow secrets, then remove AWS trust-policy changes and Azure federated credentials.
- Treat an npm install of a malicious commit, or that Packagist release, as a compromised machine.
Separation is the pattern that still holds. Do not let an agent or bot write token also publish packages or assume production roles. For a related leftover-credential case, see the LiteLLM unrevoked-key incident. Keeping agent secrets out of Git does not stop a token that can rewrite the workflow.
Frequently asked questions
Did wfx-loot exploit a GitHub Actions bug?
No. SecurityWeek reported StepSecurity’s finding that the attacker uses valid developer and bot tokens, not an Actions bug.
Does a probe pull request mean the GitHub account is stolen?
Aikido says that if the probe ran, that user is compromised even if the workflow stage did not run. Cycode adds that a docs: dependency audit notes pull request from wfx-docs is a sign the opener’s credential is stolen, and that closing it does not revoke the token.
Will secret rotation cut off the cloud access?
Not alone. AWS trust-policy rewrites and Azure federated credentials survive rotation and must be removed in each cloud account, Aikido and Help Net Security report.
Did wfx-loot publish malicious packages?
Aikido found the payload in Packagist digitalelvis/neuronai-studio 3.14.3 and in workflow-only files of two Go tags, which Go builds never run. Machines that installed or opened the Packagist package should be treated as compromised.
