Since Tuesday, 10 November, attackers have been using stolen GitHub account access tokens to inject malicious code into repositories and silently harvest secrets from GitHub Actions and connected cloud accounts. The campaign, now named wfx-loot, has been confirmed in 61,764 repositories.
This matters for almost any Swiss business that builds or maintains software, e-commerce platforms, or automated workflows. If your developers — whether in-house or an external agency — use GitHub with CI/CD pipelines connected to AWS, Azure or Google Cloud, your cloud credentials may already have been stolen, and a backdoor may already be sitting in your cloud account.
What exactly happened
Security firm Aikido, which discovered and named the campaign, found that 4,837 compromised GitHub accounts opened probe pull requests across 61,764 repositories. In at least 1,806 of those, the actual secret-stealer ran and exfiltrated data.
Where a repository's workflows had access to AWS or Azure, the malicious code didn't just steal a password — it used the stolen credentials to quietly build itself a way back in. On AWS, it opened a new IAM role inside the account. On Azure, it added extra authentication paths (Federated Credentials) to existing workflows. Both are designed to survive a normal password or key rotation.
Why "just rotate your secrets" won't fix this
This is the part business owners need to understand clearly: if the malicious code ran in even one of your repositories, rotating secrets is not the end of the job — it's the start. The backdoors stay active even after you change every password and API key, because they are independent access paths the attacker set up inside your cloud account itself.
Aikido's own guidance is blunt: if the payload ran, you should assume every secret and every cloud role available to that workflow is compromised — not just the one that was directly stolen.
What to check today
- Review GitHub Actions logs since 10 November for unusual workflow runs, unfamiliar pull requests, or unexpected GitHub App installations on your repositories.
- Check AWS IAM roles for any that trust an account you don't recognise, or any created around or after 10 November without your team's knowledge, as described in Heise's reporting on the removal steps required.
- Check Azure Federated Credentials for entries with the prefix wfx-ci- — this is the specific marker left by this campaign.
- Rotate all secrets used in affected workflows — but treat this as step two, not the whole fix.
- Remove the backdoor itself: delete the rogue IAM role or Federated Credential, not just the stolen key that created it.
- Audit third-party GitHub Apps and tokens connected to your organisation's repositories, and revoke anything you can't account for.
If you don't manage this in-house
Many Swiss SMEs rely on an external developer, agency or freelancer for their website, webshop or automated workflows. If that's you, don't assume "not my job" — ask directly: does your GitHub setup use Actions connected to a cloud account, and has anyone checked for wfx-loot indicators since Tuesday? A five-minute question today can save weeks of cleanup later.
This is exactly the kind of threat that doesn't announce itself — no ransom note, no locked screen, just a quiet door left open into your cloud infrastructure. It's also a reminder of why automation and IT security need to be reviewed together, not separately: every connected system, pipeline and integration is a potential entry point. At Flitz.ai, we help businesses automate their operations securely, and that includes making sure the connections between your tools don't become the weak link.
We'll keep watching this space. New supply-chain attacks like this one are becoming part of the normal weekly rhythm of running a business online — the businesses that check consistently are the ones that stay out of the headlines.
Switzerland.