Supply chain · Briefing
GitHub wfx-loot campaign steals CI secrets and alters cloud trust
Stolen repository access exposed workflow credentials and enabled persistent cloud access. Defenders need to investigate both GitHub identities and the cloud permissions their workflows can exercise.
Kinwilder research desk · · AI-assisted analysis
What is established
Stolen GitHub credentials powered a secret-stealing campaign beginning November 10, 2026, according to Help Net Security’s November 12 report. It describes theft of GitHub Actions secrets and cloud credentials, plus AWS trust-policy changes and Azure federated credentials that survive secret rotation. Defenders therefore face a recovery problem extending beyond repository access.
The Hacker News, published November 12, 2026, reports 4,837 hijacked accounts, probes in 61,764 repositories and execution in at least 1,806. These measure different stages of exposure. It also identifies malicious Packagist release digitalelvis/neuronai-studio 3.14.3 and workflow contamination in github.com/onuragtas/docker-env v1.0.278 and v1.0.280; Go builds do not execute those workflow files. Additional probes appeared on November 12; subsequent payload execution was unclear.
Who is behind it
Aikido named the campaign wfx-loot and assesses that its focus is CI secrets, as Help Net Security reports. This is a campaign label, not an established operator identity. The packet establishes no state association, operator location or comprehensive victim geography. Repository ownership cannot establish an attacker’s nationality.
Our analysis
Analysis: The critical boundary is between permission to change source code and permission to exercise production authority. From the attacker’s perspective, repository access becomes valuable when a change can trigger execution holding credentials or cloud identity. From the defender’s perspective, an authenticated contributor still needs constraints on what their changes may cause automation to do.
The basic principle is that permission to edit code should not automatically confer every privilege available to its build system. Review must follow the entire path: identity, repository permissions, workflow trigger, execution environment and downstream cloud role. A strong control at one point can be undermined by broader permissions elsewhere.
Analysis: Organisations with shared automation identities, multiple writable repositories or powerful cloud-connected workflows should assess whether one compromised identity could cross several projects. That is an exposure hypothesis, not a finding about additional victims. Watch for whether investigators establish private-repository impact and whether cloud persistence remains after repository recovery.
Analysis — possible AI applications: An attacker could use AI to identify valuable workflow configurations. Defenders could use it to summarise permissions and compare intended cloud trust with audit records. These are possible uses; the supplied evidence does not establish AI involvement in this campaign. Check generated conclusions against the underlying configurations and logs.
Defensive actions
Prioritise affected identities and execution environments. SafeDep’s advice, relayed by The Hacker News, is to revoke affected authors’ tokens, OAuth grants, SSH keys and sessions, enable two-factor authentication, and rotate accessible secrets and variables. For the Packagist release above, the report recommends blocking it and pinning 3.14.2 or earlier.
Our defensive guidance: Preserve repository, workflow and cloud audit evidence before cleanup. Map every cloud role reachable from suspect workflows, remove unauthorised trust relationships and investigate unexpected credential creation. Treat rotation as one recovery step; verify who can obtain replacement access.
For hunting, correlate repository changes with workflow execution, cloud identity activity and outbound network records. Help Net Security identifies the wfx-docs branch and deleted workflow histories as investigation leads. Neither an indicator match nor its absence should replace examination of execution and identity records.
Practical verification exercise: Select one representative repository and trace a hypothetical contributor change through its approval gates to every accessible cloud role. Use configuration inspection and a benign test workflow without production secrets. Can an ordinary contributor change what runs with elevated authority? Record the answer, evidence and control owner. This is a proposed exercise; Kinwilder did not perform it.
Key concepts
- CI workflow: Automation that builds, tests or publishes software after repository events.
- Trust policy: Rules determining which identities may assume a cloud role.
- Federated identity: Access based on another system’s identity assertions, potentially without a stored cloud password.
- Secret rotation: Replacing credentials; it does not itself remove every alternative route to access.
Limits
Both campaign reports substantially relay Aikido’s findings, so publisher count is not independent confirmation. Initial credential acquisition, total private-repository exposure, affected sectors and countries, and complete containment are unestablished in this packet. The separate Claude Code leakage report does not establish how this campaign obtained credentials. Kinwilder did not reproduce the malware, validate the counts or test recovery.
Kinwilder briefing: AI-written analysis of public reporting, checked in a separate AI review against the linked sources. No human expert review or independent reproduction is implied.