What happened
Since 15 September 2026, Wiz Research has tracked a campaign it calls Gheist that abuses compromised GitHub tokens at scale. For each repository a token can reach, the tool creates a branch named ci-sync- followed by six random characters, then commits a file at .github/workflows/sync-check.yml with the commit message ci: sync config. The push triggers the workflow, which prints the repository's secrets into its own log in base32 so GitHub's masking does not catch them. The tool then downloads the log through the GitHub API and deletes the run seconds later. Its API requests carry the user agent gheist.
Wiz has recovered more than 13,500 planted branches from more than 850 compromised accounts, from personal projects to enterprise private repositories. The credentials appear to come from infostealer logs and earlier supply-chain compromises.
Timeline
- 28 Jul 2026: GitHub begins holding potentially malicious workflow runs in public repositories until a collaborator approves them.
- 15 Sep 2026: Gheist campaign begins.
- 28 Sep 2026: Tool B adds timeout-minutes: 6 and an environment matrix to reach environment-scoped secrets.
- 19 Oct 2026: Tool B adds a base32 separator and a sync-host job targeting self-hosted runners.
- 24 Oct 2026: Attack ongoing and evolving. Roughly two thirds of implicated accounts are no longer on GitHub.
Am I affected?
Public repositories are largely protected: every public Gheist run Wiz checked sits at action_required, so the payload never ran. The hold does not apply to private repositories or to GitHub Enterprise Server. There, audit logs show runs on ci-sync-* branches completing and then being deleted by the gheist user agent.
You are exposed if a token with access to your private repos or GHES was stolen, and more so if your repos hold deployment environments with production credentials, or register self-hosted runners.
What to do now
- Search every repository and GHES organisation for branches named ci-sync- plus six random characters whose only change is a new .github/workflows/sync-check.yml with the message ci: sync config. Delete them.
- Treat any secret in an affected repository as compromised. Rotate repository secrets, environment-scoped secrets, OIDC-linked cloud roles and automation account tokens.
- Review GitHub tokens and personal access tokens for the affected accounts. Revoke and reissue them.
- If a repository had deployment environments, rotate the production credentials first, since the environment matrix is designed to reach them.
- For self-hosted runners, assume host compromise. Rotate cloud instance-role credentials, Kubernetes service account tokens, and anything reachable through the Docker socket, then rebuild the runner.
- Check AWS Secrets Manager and similar stores for enumeration, since Wiz saw stolen cloud credentials used to list secrets hours after the initial dump.
How to hunt
In GitHub audit logs, look for workflow runs on ci-sync-* branches deleted within a minute of completing, and for any activity from the user agent gheist.
If your workflows use OIDC to authenticate to the cloud, check cloud audit logs for role assumptions or token exchanges whose subject includes a ci-sync- branch. That proves Actions ran on an attacker branch even if you do not collect GitHub logs. In AWS, CloudTrail shows your own workflows assuming roles on those branches.
On self-hosted runners, look for the sync-host job, for the helper files .gdmp_pat, .gdmp_patg and .gdmp_sweep, and for log headers of the form ===== gdmp-pivot: =====.
What does not help
Setting permissions: {} on the job does not stop this. It restricts the job's GITHUB_TOKEN, which the attacker does not need, but it does not restrict the secrets context that the payload reads.
Blocking an attacker domain does not help either. The secrets leave through GitHub's own API, so there is no outbound connection or attacker domain to block. Note that Gheist is distinct from GhostAction, which exfiltrates to 193.32.204[.]199.
Sources
- Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbles, Wiz Research, 25 Oct
- 'Gheist' Weaponizes GitHub Tokens to Steal Cloud Secrets, Dark Reading, 26 Oct
- Gheist Uses Stolen GitHub Tokens to Steal Private Repository Secrets via Actions Logs, The Hacker News, 26 Oct
