wfx-loot: 4,837 GitHub Accounts Weaponized to Steal CI/CD Cloud Credentials

The wfx-loot attack chains three steps into a supply chain credential theft pipeline. First, attackers compromised 4,837 GitHub accounts through credential stuffing, phishing, or infostealer logs. With these accounts, they opened pull requests against thousands of public repositories, injecting a roughly 1,500-line shell script into existing workflow files, npm install hooks, or new workflows on throwaway branches named wfx-docs or matching the chore/* pattern.

Second, when any user or automated CI system triggered a workflow run on the modified branches -- including automated checks triggered by the pull request itself -- the shell script executed. The script collected every secret available to the workflow runner: GitHub Actions secrets, cloud provider credentials loaded from environment files, SSH keys, session tokens, API keys for AI platforms, and any secret injected via CI environment variables.

Third, the script exfiltrated the collected credentials via HTTPS POST requests to attacker-controlled endpoints and simultaneously created persistence backdoors in every cloud environment it could reach. For AWS, it modified IAM role trust policies to allow any repository under attacker control to assume the role via OIDC. For Azure, it created federated identity credentials on app registrations. For GCP, it generated service account keys. All three persistence mechanisms are independent of the GitHub secrets themselves -- they live in your cloud IAM configuration, not in GitHub.

The TeamPCP and Megalodon GitHub Actions campaigns in May 2026 demonstrated this attack pattern at smaller scale. wfx-loot scaled the same approach to nearly 62,000 repositories in 48 hours using hijacked accounts rather than compromised third-party Actions.

Most incident response playbooks treat secret rotation as the primary remediation for credential theft. wfx-loot's persistence mechanism makes that instinct dangerous for this campaign specifically.

When the payload script successfully authenticates to Azure using stolen credentials, it calls the Azure AD API to create a new federated identity credential on the organization's app registration. The new credential is named using the wfx-ci- prefix and configured to trust OIDC tokens issued by GitHub Actions from any repository the attacker controls. After creating this credential, the attacker no longer needs the stolen GitHub secret -- they can generate a fresh GitHub OIDC token from any repository they own, present it to Azure, and authenticate as the compromised app registration.

Rotating your GitHub Actions secrets does not remove the federated credential from your Azure app registration. The backdoor lives in Azure AD, not in GitHub. The only remediation is to explicitly list and delete every federated identity credential on your app registrations and verify no wfx-ci- prefixed entries exist.

The AWS persistence mechanism works similarly. The payload modifies IAM role trust policies to add wildcard conditions on the sub claim in GitHub OIDC tokens, allowing any repository to assume the role. After this modification, the attacker can create a repository named to match the trust policy pattern and authenticate without any secret. Remediating this requires reviewing every IAM role trust policy that includes GitHub as an OIDC identity provider and reverting any wildcard conditions that do not match your expected workflow paths.

Chainguard's analysis confirms that absence of wfx-loot artifacts in the runner environment does not prove clean containment -- the cloud backdoors can persist even after the malicious branches are deleted and GitHub secrets rotated.

The attack targets any organization meeting three conditions: a public GitHub repository, GitHub Actions workflows enabled, and cloud provider credentials available to those workflows. This describes the standard CI/CD configuration for the majority of software organizations using GitHub.

The affected credential types span the full cloud provider stack. AWS access keys and IAM roles configured for OIDC federation with GitHub are the highest-value targets -- they provide direct access to cloud infrastructure, S3 buckets, Secrets Manager, and Lambda functions. Azure service principal credentials and app registrations with federated identity configured for GitHub are equally high risk. GCP service account keys provide access to Cloud Storage, GKE clusters, and Secret Manager. The payload also collects SSH keys, Kubernetes cluster tokens, container registry credentials, NPM tokens, PyPI tokens, and API keys for OpenAI, Anthropic, and other AI platforms.

Technology and financial services organizations face the highest blast radius given their typical CI/CD pipeline density. Healthcare and government organizations running GitHub-based infrastructure pipelines are also directly in scope. Any organization that hosts its own GitHub Enterprise Server instance and allows GitHub Actions is exposed to the same attack class, though the wfx-loot campaign specifically targeted github.com public repositories.

The LiteLLM supply chain attack in mid-2026 demonstrated that CI/CD credential theft at scale translates directly to downstream infrastructure compromise. wfx-loot targets the same attack surface at an order of magnitude larger scope.

The indicators below represent confirmed artifacts from the wfx-loot campaign. The cloud IAM indicators (Azure federated credentials, AWS CloudTrail session names) are the highest-priority checks -- they confirm active post-compromise persistence regardless of whether the original GitHub branches or secrets still exist.

The two rules below target the highest-confidence wfx-loot indicators: AWS CloudTrail session names matching the attacker's OIDC token pattern and Azure AD federated identity credential creation with the wfx-ci- prefix. Both carry experimental status; validate against your cloud audit log format before enabling automatic blocking.

The remediation steps below prioritize cloud IAM audit before secret rotation specifically because wfx-loot's persistence mechanism makes rotation incomplete without the IAM cleanup. Work through these in order: steps 1 through 4 close active backdoors; steps 5 through 7 reduce future exposure.

GitHub Actions is now one of the highest-value attack surfaces in enterprise cloud security. The pipeline represents a privileged bridge between developer workstations, source code, and production cloud infrastructure -- and unlike most enterprise systems, its permissions are managed at the repository level by developers who may not have security training.

The wfx-loot campaign's scale -- 61,764 repositories probed in 48 hours using hijacked accounts -- reflects an attacker discovery that GitHub credential theft via supply chain injection is cheaper and more scalable than direct cloud credential targeting. A single compromised GitHub account with write access to 20 repositories is worth more than 20 individually phished cloud passwords because each pipeline secret includes cloud credentials with production deployment permissions.

The persistence mechanism makes this worse than a standard credential theft incident. Standard playbooks treat the attack as a data exfiltration event resolved by rotation. wfx-loot turns each compromised pipeline into an ongoing identity federation backdoor, shifting the attack from credential theft to persistent cloud identity compromise. The window between initial compromise and cloud IAM modification may be seconds -- the shell script creates Azure federated credentials immediately after authenticating.

Organizations that run more than 10 GitHub repositories with cloud-connected Actions workflows should treat GitHub Actions permission hygiene as an equivalent priority to cloud IAM hygiene. The two are now the same attack surface.