GitHub Account Hijack: Revoke Access Before You Rotate
Attackers did not break GitHub this week. They logged in. This GitHub account hijack began on 10 November, when stolen credentials were used to push a secret-stealing script into code pipelines across thousands of repositories. If your developers use GitHub Actions, the order in which you clean up decides whether the attacker keeps their access.
What happened in the GitHub account hijack
Aikido Security, which first reported the campaign, says that from about 12:45 UTC on 10 November a threat actor used stolen GitHub tokens to open “probe” pull requests titled docs: dependency audit notes. Aikido counted 4,837 compromised accounts across 61,764 repositories. It found signs the payload ran in at least 1,806 repositories.
The script collects GitHub Actions secrets, cloud credential files and AI provider keys. Aikido says it also plants persistence designed to outlast credential rotation, including an AWS trust policy opened to any AWS account and new Azure federated credentials. Within about a minute it reverts its own change and deletes the workflow run. Aikido names the campaign wfx-loot. Safeguard’s write-up pulls together the other researchers’ findings. How the credentials were stolen has not been published.
Why it matters if you run a business with developers on GitHub
Nobody exploited a flaw here. Each stolen token let the attacker act as a real developer, with that developer’s write access. That includes repositories the developer did not own but could reach as a collaborator. Aikido counted 10,431 pull requests into repositories the account did not own.
Then the workflow did the rest. A workflow that runs in your pipeline holds your secrets. Push a malicious step into it and those secrets are readable. That is why one stolen token can become your cloud account.
The cleanup order matters. Say you rotate every secret first, while the attacker’s token still works. They can push again and collect the new ones. Safeguard, citing Endor Labs, reports that more than 1,800 repositories hit early in the campaign were hit again by a later version. Rotation also does nothing about the backdoors the stealer plants in your cloud account, because those are not secrets you can rotate.
So the order is: cut off the attacker, remove what they left behind, then rotate. A workflow that holds many secrets deserves the same care as a secret rotation plan for the whole company. The entry on API key exposure explains how keys leak.
Two other points. Run logs may be deleted, so the best sign the stealer ran is a gap in workflow run numbers. And GitHub is not the only exposure. A stolen token is only one of the ways a login ends up in a criminal’s hands.
What to do this week
- Ask your IT person to search every GitHub organisation you use for pull requests titled “docs: dependency audit notes” and branches named “wfx-docs”, and to treat any account that opened one as compromised.
- For each affected account, have them revoke personal access tokens, OAuth app grants, SSH keys and active sessions first, then reset the password and turn on phishing-resistant multi-factor authentication.
- Have them check your AWS and Azure accounts for roles that trust any AWS account, and for Azure federated credentials named “wfx-ci-“, and delete what you did not create.
- Only then rotate every secret and cloud key that the affected repositories’ workflows could reach, including AI provider keys.
- Have them look for gaps in workflow run numbers around the dates above, and set the default GITHUB_TOKEN permission to read-only.
How Wolfcore helps
Breachy is our breach exposure monitor. It checks your team’s email addresses against known data breaches, scores the exposure and walks you through the fixes. It will not find a stolen GitHub token, and nobody has said how these logins were taken. What it does show is which of your staff logins are already out there, so you can reset them before someone uses them. Check your exposure with Breachy.
Ruben Selby, founder and penetration tester at Wolfcore
Frequently asked questions
Was GitHub hacked? No. Aikido says the attacker used stolen GitHub tokens to act as real developers, so the accounts were logged into, not broken.
Why revoke access before rotating secrets? If the attacker’s token still works, they can push again and collect the new secrets. Rotation also does not remove the cloud backdoors the stealer plants.
How do I know if my repositories were hit? Search for pull requests titled “docs: dependency audit notes” and branches named “wfx-docs”, and look for gaps in workflow run numbers.
Sources
- Aikido Security: wfx-loot campaign pushes CI secret stealer to tens of thousands of repositories (12 Nov 2026)
- Safeguard: wfx, 4,837 hijacked GitHub accounts, what to check and rotate (13 Nov 2026)
Related reading: Infostealer malware: why a password reset is not enough