Source: Wiz Blog
Wiz Research has published details of Gheist, an automated campaign that takes stolen GitHub tokens and turns them into secret harvesting pipelines. Since 15 September 2026 the researchers have recovered more than 13,500 planted branches pushed from more than 850 compromised accounts, ranging from personal projects to the private repositories of enterprise organisations. The campaign was still active and evolving as of 24 October 2026, and about two thirds of the implicated accounts had disappeared from GitHub, which Wiz believes reflects a response after it reported the activity.
How the attack works
For every repository a stolen token can reach, the tool creates a branch named ci-sync- followed by six random characters and commits a single workflow file, .github/workflows/sync-check.yml, with the commit message “ci: sync config”. The workflow prints the job environment and every secret the job can read, encoded in base32. GitHub masks secret values in workflow logs only when they appear verbatim, so the encoded values slip past the masking and are printed in full. The tool then downloads the log through the GitHub API and deletes the run seconds later. Because the secrets leave through GitHub itself, there is no attacker domain or outbound connection to block.
A later variant adds a job per deployment environment, so environment scoped secrets, often production credentials, are printed too. On 19 October a new version also pushed a sync-host job targeting repositories with self-hosted runners. That job sweeps the host for 31 token formats including keys for AI providers, private keys, .env files, Terraform state and shell history, reads the environment of every process from /proc, and reaches through the Docker socket to repeat the search on the host filesystem, along with AWS instance role credentials, GCP and Azure metadata, runner credential files and the Kubernetes service account token. In enterprise organisations Wiz saw the tool cycle through tokens of several users and automation accounts within minutes, and hours later cloud credentials from the same organisation were used to enumerate AWS Secrets Manager.
Why the GitHub safeguard is not enough
Since 28 July 2026 GitHub has held potentially malicious workflow runs in public repositories until a collaborator approves them. Every public Gheist run Wiz checked was still waiting for approval, so the payload never ran there. The problem is that the hold applies to public repositories on github.com only. In private repositories and GitHub Enterprise environments the audit logs show the planted workflows finishing and being deleted, and AWS CloudTrail logs show the organisations’ own workflows running on those branches. Deleting the branch does not undo the exposure either: Wiz stresses that every secret the repository could read should be rotated, and the token that pushed the branch revoked.
For any organisation building on GitHub this is a reminder that a token with write access to a repository is effectively a credential that can read every secret configured in it. Audit your branches for unexpected ci-sync- prefixes and sync-check workflows, enforce least privilege and short lived tokens, restrict which actors can run workflows against deployment environments, and treat any suspicious run on a self-hosted runner as a host compromise. If you want help reviewing GitHub Actions security, secret rotation strategy or CI/CD hardening, contact us for professional advice.