Gheist campaign plants secret-dumping workflows using stolen GitHub tokens

Gheist is an ongoing campaign that uses stolen GitHub tokens to plant a workflow in every accessible repository. Since September 15, 2026, researchers have recovered more than 13,500 affected branches linked to over 850 accounts. The workflow encodes repository secrets in base32 to evade GitHub’s log masking, then retrieves the output through GitHub’s API and deletes the run. Restricting the workflow’s GitHub token permissions does not prevent access to secrets, including environment-scoped credentials. In private repositories and enterprise environments, workflows ran and cloud credentials were used to enumerate AWS Secrets Manager. A later variant also targeted self-hosted runners, searching hosts for tokens, private keys, cloud credentials and other sensitive files, though parts of that payload were faulty.

GitHub’s approval hold has stopped the malicious workflows from running in public repositories, but it does not protect private repositories or GitHub Enterprise Server. The campaign continues to evolve; roughly two-thirds of implicated accounts were unavailable by October 24. Some compromised accounts also participated in malware distribution and cryptomining, while traced credential sources include infostealer logs and earlier supply-chain compromises. Defenders should search for `ci-sync-` branches, short-lived deleted workflow runs, the `gheist` user agent and cloud role assumptions tied to those branches. For affected repositories, rotate all accessible secrets and revoke the tokens used to push the workflows. Treat any targeted self-hosted runner as compromised, and reduce future exposure with reviewed production environments, narrowly scoped OIDC trust, short-lived tokens and isolated ephemeral runners.