Gheist Abuses Stolen GitHub Tokens, Wiz Says

Security teams that run GitHub Actions in private or enterprise repositories should check for branches named “ci-sync-” and rotate every secret those repositories can reach, according to Wiz Research, which on 25 October published details of a token-abuse campaign it calls Gheist. Wiz says deleting the malicious run or branch afterwards “doesn’t undo the exposure”.

The campaign uses stolen GitHub credentials to push a small workflow file that prints a repository’s secrets into its own build logs in encoded form. A protection GitHub introduced in July held those runs in public repositories so that they never executed. Wiz says the same protection does not cover private repositories or GitHub Enterprise Server, and that it has seen successful theft there, followed by activity against cloud accounts.

In brief

Wiz says it has recovered more than 13,500 planted branches from more than 850 compromised GitHub accounts since 15 September.
GitHub’s approval hold for suspicious workflow runs, introduced on 28 July, applies only to public repositories on github.com.
Wiz’s advice: hunt for “ci-sync-” branches, rotate exposed secrets, revoke the tokens and move away from personal access tokens.

The fix Wiz recommends is rotation, not clean-up

Wiz’s guidance is split into hunting, response and hardening. For hunting, it says to look for branches named “ci-sync-” followed by six random characters, where the only change is a new file at .github/workflows/sync-check.yml with the commit message “ci: sync config”. It also points to workflow runs deleted within a minute of finishing, which show up in audit logs, and to cloud audit logs where an OIDC role assumption carries a “ci-sync” branch in its subject.

For response, the key line is: “Rotate every repository, organization and environment secret available to an affected repository.” Wiz also says to revoke the tokens that pushed the commits and to “check their owners’ devices for infostealers”. Any self-hosted runner that executed the workflow should be treated as compromised. And where GitHub has paused a suspicious run, Wiz’s advice is blunt: “Don’t approve held sync-check runs.”

For hardening, Wiz recommends requiring reviewers on environments that hold production secrets, limiting cloud OIDC trust to protected branches or environments, and using “GitHub Apps or short-lived fine-grained tokens instead of personal access tokens”. Self-hosted runners, it says, should be ephemeral and should not have access to the Docker socket or unrestricted cloud metadata.

How Gheist turns a stolen token into leaked secrets

Wiz says it has tracked Gheist since 15 September and has “recovered more than 13,500 planted branches from more than 850 compromised accounts, ranging from personal projects to enterprise organizations’ private repositories”. The commits are unsigned and are authored as the owner of the stolen token.

The workflow dumps the repository’s secrets and environment into the job log after encoding them in base32. That step matters because, as Wiz puts it, “GitHub masks secret values in logs only when they appear verbatim”. An encoded secret does not match, so it prints in full. The attacker then reads the log back through GitHub’s API. “Because the secrets leave through GitHub’s own API, there is no attacker domain or outbound connection to block,” Wiz says.

In enterprise organisations, Wiz says it saw the tool cycle through tokens belonging to several users and automation accounts within minutes, clone private repositories, and then, hours later, cloud credentials from the same organisation being used to enumerate AWS Secrets Manager. A later variant added a job aimed at self-hosted runners that hunts for API keys, private keys and cloud credentials, although Wiz says “this job is buggy” and misses some of its targets.

Wiz researcher Rami McCarthy told Dark Reading that Wiz estimates the campaign affected “on the scale of a dozen companies”. He added that Wiz had “not seen consistent or automated abuse outside of mass cloning of GitHub repositories and the core credential theft”. Wiz says roughly two-thirds of the implicated accounts are no longer available on GitHub, which it reads as likely response activity after it reported the campaign to GitHub.

GitHub’s July control held every public Gheist run

GitHub announced the control in a changelog post on 28 July. It said attackers were using “compromised GitHub credentials to push malicious GitHub Actions workflows that steal CI/CD credentials”, and that GitHub Actions “now holds certain workflow runs for approval before they start”. A held workflow “won’t execute until a repository collaborator with write access reviews and approves it”, and approval has to come through an authenticated web session, so a stolen token alone cannot release it.

Wiz says every public Gheist run it checked was sitting in that held state. “The control worked, and the malicious payloads never ran,” it wrote. The limit is spelled out in GitHub’s own post: “This protection currently applies to public repositories on github.com only. GitHub Enterprise Server doesn’t add this protection at this time.”

Private repositories are now the soft target for token theft

Gheist shows a protection doing its job and an attacker simply moving to where it does not apply. GitHub’s hold appears to have neutralised a mass campaign in public repositories without any action from repository owners. But the organisations with the most valuable secrets tend to keep their code in private repositories or on GitHub Enterprise Server, which is exactly where the hold is absent. A stolen token with write access is enough to run code in those repositories’ pipelines.

The defence that matters is therefore credential hygiene rather than detection. Wiz’s own write-up says there is no attacker infrastructure to block, and the malicious change is a single small file pushed under a legitimate user’s name. Short-lived, narrowly scoped credentials limit what a stolen token can do, and approval gates on production environments put a human in front of the secrets that matter most. The Meta GitHub intrusion earlier this month, where Meta said an employee’s stolen login was used to get into some of its code repositories, showed how far a single valid credential can reach.

The pattern also fits a wider run of attacks on developer tooling, from the malicious LiteLLM release on PyPI to backdoored OVHcloud CLI releases, where the build and release pipeline is the target. Wiz traced some of Gheist’s stolen tokens to infostealer logs and to earlier supply-chain compromises. Each leak feeds the next campaign, which is why rotation after exposure is not optional. GitHub has not said whether it plans to extend the hold to private repositories or Enterprise Server.