Gheist Campaign Siphons Secrets From Private GitHub Repos Using Stolen Tokens
Wiz Research says the automated attack has planted more than 13,500 malicious branches across 850-plus compromised GitHub accounts since mid-September, with private repositories and Enterprise tenants bearing the brunt.
Key points
- Wiz Research has tracked more than 13,500 malicious branches planted across over 850 compromised GitHub accounts since mid-September 2026 in a campaign it calls Gheist.
- The attack writes a workflow file named sync-check that prints a repository's stored secrets into the build log, then pulls the log through the GitHub API and deletes the run within seconds.
- A GitHub safeguard is blocking the trick in public repositories, but Wiz says it has seen successful theft inside private repositories and GitHub Enterprise environments.
- Roughly two-thirds of the implicated accounts were no longer live on GitHub as of 24 October 2026, which Wiz reads as cleanup activity after it reported the campaign.
- The attacker's API calls carry the user agent string "gheist," the detail that gave the campaign its name.
Someone is working through a large stash of stolen GitHub login tokens and using them to vacuum up passwords and API keys from private software projects.
That's the picture Wiz Research laid out this week in its writeup of a campaign it has named Gheist. The Hacker News first flagged the research to a wider audience.
A GitHub token is a long character string that acts like a password for automated access to a developer's code. Hold one, and you can do almost anything the owner can do, including pushing new code into private projects.
How does the attack actually work?
The tool creates a new branch in each reachable repository, named ci-sync- followed by six random characters, and commits a workflow file called sync-check. GitHub Actions, the service that automatically runs scripts when code changes, picks it up and executes it.
It then prints the repository's stored secrets, cloud keys, deployment passwords, third-party API tokens, straight into the run's log. The attacker downloads that log through GitHub's own API and deletes the workflow run seconds later. Every API call from the tool carries the user agent gheist, a tag identifying the software making the request, which is what gave Wiz the thread to pull.
Who is actually affected?
Private repositories and GitHub Enterprise customers. Wiz says a recent GitHub control is blocking the technique in public repositories, but the same control doesn't stop it inside closed environments, where most commercial source code lives.
The 850-plus compromised accounts Wiz counted range from hobby projects to enterprise organisations. Wiz hasn't named victims.
Scale matters here because the stolen material isn't the code itself but the secrets baked into the build pipeline. One leaked cloud key can open a path into production systems that have nothing to do with GitHub. We reported in September on how a poisoned coding library led to 170 private repos being copied at CrowdSec, a reminder that the pipeline, not just the code, is the target.
| Detail | Figure |
|---|---|
| Campaign tracked by Wiz from | mid-September 2026 |
| Malicious branches recovered | 13,500+ |
| Compromised accounts seen | 850+ |
| Accounts no longer on GitHub by 24 Oct | roughly two-thirds |
| Branch naming pattern | ci-sync- plus 6 random characters |
| Workflow filename | sync-check |
What should developers and security teams do now?
Treat any GitHub token that's sat in a config file or a CI system as potentially exposed, and rotate it. Check your organisation's audit log for push events creating branches matching the ci-sync- pattern, and for workflow runs deleted within seconds of completing.
For Enterprise administrators, the practical move is reviewing which personal access tokens and OAuth apps hold write access to private repositories, and requiring that Actions workflows run with the minimum secrets they need rather than the full repository set.
GitHub's public-repo guardrail is doing real work here, blocking the exact exfiltration path in the place researchers can see. The uncomfortable corollary is that the campaign kept running, quietly, in private tenants nobody outside the customer can audit. That's the gap worth watching as GitHub decides whether to extend the same control inward.
