Wiz has been watching a campaign since September 15 that borrows stolen GitHub credentials to drop a workflow into every repository those credentials can touch, and the job’s only purpose is to print secrets into a GitHub Actions log. Seconds after the job finishes, the attackers grab the output via GitHub’s API and erase the record of it. Private repositories and GitHub Enterprise were where it worked.
Every attempt gets its own branch, ci-sync- followed by a random six-character tail, carrying one added file at .github/workflows/sync-check.yml whose commit message reads ci: sync config. No signature is attached, and the author field simply names the account the credential belongs to. The push is what starts it.
Inside, the job prints its environment and every secret it can read, encoded as base32. GitHub strips raw values from logs, but its docs concede that masking stops once a value is transformed, so the encoded text appears intact. Declaring an empty permissions block limits a job token the intruders never need, leaving secret access untouched.
Cleanup means rotation, not deletion
Across more than 850 compromised accounts, Wiz recovered upwards of 13,500 branches, spanning hobby projects and private enterprise code. At enterprise customers, Wiz watched it work through credentials for several staffers and service accounts in minutes, clone private repositories, then hours on use the company’s cloud access to list AWS Secrets Manager contents.
GitHub now holds suspicious runs in public projects for approval, which stopped every public attempt Wiz examined. It does not apply to private repositories or Enterprise. Roughly two-thirds of the accounts involved had vanished from GitHub by October 24.
Any write-capable token that leaked should mean revoking it and rotating everything the repository could reach. Deleting the branch or the run fixes nothing.
