An automated campaign dubbed Gheist has used stolen GitHub access tokens to plant malicious workflows in repositories and steal their secrets, according to research published by cloud security company Wiz. Wiz says it has tracked the campaign since 15 September and recovered more than 13,500 planted branches linked to more than 850 compromised accounts.

The attack works by abusing permissions the stolen token already holds. The tool creates a branch named ci-sync- followed by six random characters and commits a workflow file, .github/workflows/sync-check.yml, with the message "ci: sync config". When the branch is pushed, GitHub Actions runs the workflow, which prints repository secrets and environment variables after encoding them in base32. GitHub normally masks recognised secret values in workflow logs, but that protection only applies when values appear verbatim, so an encoded secret prints in full. The tool then downloads the log through GitHub's own API and deletes the run within seconds.

Private repositories escaped the safeguard that stopped public runs

GitHub introduced an approval hold on 28 July 2026 that stopped every public-repository run Wiz checked. That safeguard does not cover private repositories or GitHub Enterprise Server, where Wiz found evidence of runs completing and then being deleted. Cloud audit logs showed workflows on attacker-created branches assuming AWS roles. A second variant seen on 19 October targets self-hosted runners, hunting for 31 credential formats.

Wiz says the campaign was still active as of 24 October, although roughly two-thirds of the identified accounts were no longer available on GitHub. The firm has not established how many organisations had secrets exposed or how the attackers obtained the tokens. Affected users should rotate every secret a repository could read and revoke the pushing token, since deleting the branch or run does not undo the exposure.