Gheist: stolen GitHub tokens plant a secret-dumping workflow in every repository they reach; GitHub's July approval hold stops it on public github.com repositories but not on private ones or GitHub Enterprise Server
Gheist abuses stolen GitHub tokens to dump secrets through Actions; GitHub's hold covers public repositories only
Defender actions
- In every GitHub organisation your teams or suppliers administer, private repositories and GitHub Enterprise Server included, search for branches named ci-sync- plus six random characters that add only the workflow file sync-check.yml, and for any workflow run on them; for every hit, rotate all repository, organisation and environment secrets that repository could read and revoke the token that pushed the commit, because deleting the run or the branch does not undo the exposure.
Analysis
Wiz Research has tracked since 2026-09-15 a campaign it calls Gheist, after the user agent on its API calls, that uses stolen GitHub access tokens to create a branch and commit a workflow named sync-check in every repository each token can reach: more than 13,500 planted branches from more than 850 compromised accounts, from personal projects to private enterprise repositories (Wiz, 2026-10-25). Wiz traces the tokens to infostealer logs and earlier supply-chain compromises (Wiz, 2026-10-25). The push triggers the workflow, which prints the repository's secrets, and those of any deployment environment, into its own run log; GitHub masks secret values only when they appear verbatim, so a base32-encoded value prints in full, the tool downloads the log through the GitHub API and deletes the run seconds later, and because the secrets leave through GitHub's own API there is no attacker domain or connection to block (Wiz, 2026-10-25). In enterprise organizations the tool cycled through the tokens of several users and automation accounts within minutes and cloned private repositories before planting the workflow; hours later cloud credentials from the same organization were used to enumerate AWS Secrets Manager (Wiz, 2026-10-25). Around 2026-10-19 the second variant added a job for repositories with a self-hosted runner that searches the host, and through the Docker socket its root filesystem, for tokens, private keys, environment files and Terraform state; Wiz calls the job buggy (Wiz, 2026-10-25).
Since 2026-07-28 GitHub holds potentially malicious workflow runs in public repositories until a collaborator approves them, and every public Gheist run Wiz checked stayed held; the hold applies to public repositories on github.com only and not to GitHub Enterprise Server (Wiz, 2026-10-25; GitHub, 2026-07-28). In private repositories and GitHub Enterprise environments Wiz saw runs on the attacker branches complete and be deleted, and cloud audit logs showed the organizations' own workflows running on those branches and assuming AWS roles (Wiz, 2026-10-25). As of 2026-10-24 Wiz called the attack ongoing and distinct from the earlier GhostAction campaign (Wiz, 2026-10-25).
Triage: the planted commit is unsigned but authored as the token's owner, so the author name alone proves nothing; one new workflow file with a fixed commit message on a branch the owner did not create is the pattern (Wiz, 2026-10-25).
Cited evidence
We have recovered more than 13,500 planted branches from more than 850 compromised accounts, ranging from personal projects to enterprise organizations' private repositories.
GitHub masks secret values in logs only when they appear verbatim.
Unfortunately, that hold doesn't apply to private repositories or GitHub Enterprise Server.
This protection currently applies to public repositories on github.com only.
Sources2
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.