4,837 hijacked GitHub accounts probed 61,764 repos; at least 1,806 ran a secret stealer

01The pull request knocks; a push does the stealing

The theft does not come through the pull request. A stolen token that can write to a repository can also add or change the workflow files that GitHub Actions runs, and GitHub’s own guidance says “any user with write access to your repository has read access to all secrets configured in your repository.”³ Aikido saw three ways in: about 1,500 lines added to an existing workflow, a new workflow file on a throwaway branch, or an npm “postinstall” hook that runs a script on any install.¹

The script collects Actions secrets, the workflow’s own GitHub token, cloud credentials, AI service keys and key files. It then uses GitHub’s sign-in tokens for clouds (OIDC) to open cloud sessions, and tries to stay in: it posts fake “passed” results under the names of a repository’s required checks, rewrites an AWS role to trust any account, and adds a federated credential to Azure applications that outlives every rotated secret.¹ Aikido found the payload carried into two published packages through automated release jobs, but reads the aim as CI secrets, not spreading through packages.¹

Aikido does not say how the accounts’ credentials were stolen. Accounts hit by an October campaign were “significantly more likely than baseline” to be hit again, though it assesses the two as distinct campaigns.¹ BleepingComputer reported that some of the hijacked accounts belonged to Fortune 100 companies, the US General Services Administration, the French government, Nextcloud and WebdriverIO; it did not say what was taken from them.²

02What to check, and the settings that shut the door

Look for a wfx-docs branch, the probe pull request and gaps in workflow run numbers after 10 November. If the payload ran, Aikido’s advice is to treat every secret and cloud role available to that repository’s workflows as compromised.¹ GitHub’s documentation offers four controls that each break one step:

• Environment secrets with required reviewers. They are “only available to workflow jobs that reference the environment”, and a job “cannot access environment secrets until one of the required reviewers approves it.”⁴
• Cloud roles that trust one environment or branch. The cloud checks the OIDC token’s subject against the role’s conditions, such as environment:prod or refs/heads/main, so a token minted on a throwaway branch does not match.⁵
• A named source for each required check. Branch protection can require a check from one app; “if the status is set by any other person or integration, merging won’t be allowed.”⁶
• A read-only default for the workflow token, raised only for the jobs that need more.³