TL;DR: Somebody stole a pile of GitHub tokens and built a machine to spend them. It pushed one small file into every repository it could reach, read the secrets out loud, then wiped the evidence before anyone woke up.
What Happened?
Researchers have tracked the campaign since September 15, 2026, and named it after the user agent stamped on its API calls: gheist. For every repository a stolen token can reach, the tool creates a branch called ci-sync- plus six random characters and commits a single workflow file, sync-check.yml, with the message “ci: sync config”.
The workflow prints the repository secrets into its own run log in base32. GitHub masks secrets only when they appear word for word, so encoded values sail straight through. The operator then pulls the log through the API and deletes the run seconds later. More than 13,500 planted branches have been recovered across more than 850 compromised accounts.
What’s the Impact?
Nothing ever leaves GitHub. There is no attacker domain to block and no strange outbound traffic to spot. Deleting the branch does not undo the exposure either. In enterprise environments, the tool cycled through several user and automation accounts within minutes, cloned private repositories, and hours later cloud credentials from the same organization were seen enumerating AWS Secrets Manager.
Why Public Repos Got Lucky
Since July 28, 2026, GitHub has parked suspicious workflow runs in public repositories until a human with write access approves them. Every public run researchers checked sat frozen at that gate and never executed. Private repositories and GitHub Enterprise Server get no such hold. That is where runs completed, got deleted, and where cloud role assumptions later turned up in audit logs. Roughly two-thirds of the implicated accounts have since vanished from GitHub, suggesting cleanup is already underway.
It Is Getting Greedier
Around October 19, one variant added a second job aimed at runners teams host themselves. It hunts 31 token formats, private keys, environment files, Terraform state, and the Kubernetes service account token, then pivots through the Docker socket to the host filesystem. Researchers call the job buggy and have not seen it succeed. Buggy today is not the same as buggy next month.
Indicators of Compromise (IOCs)
What to hunt for before you rotate anything.
Published indicators for the campaign abusing stolen GitHub tokens. Nothing here is a domain or an IP, because nothing ever left GitHub. Hunt the behaviour, not the infrastructure.
One caveat worth reading twice. The environment matrix variant differs per repository, so it has no fixed blob SHA. Hash matching alone will miss it. And a separate campaign using different workflow files exfiltrates to its own IP address, so do not blend the two indicator sets.
How to Avoid This
- Rotate every repository, organization, and environment secret reachable from an affected repo.
- Revoke the pushing tokens and sweep those laptops for infostealers.
- Swap personal access tokens for GitHub Apps or tokens that expire fast and are scoped tightly.
- Require human reviewers on any environment holding production secrets.
- Run your own runners as throwaway hosts with no Docker socket access.
Your Pipeline Deserves a Teammate Who Reads the Audit Log
A deleted workflow run looks like nothing on a Monday morning dashboard. Somebody still has to connect that gap to a cloud role assumption three hours later, and most teams simply do not have the hours.
- AI Teammates watch pipeline and cloud audit trails together, so a vanished run and a surprise role assumption become one case instead of two ignored events.
- The Red Teammate tests which tokens and runners are actually reachable, and defensive Teammates harden what it proves is exposed.
- Secret rotation, branch cleanup, and owner notification run as governed work with your approvals in the right places.
- Every action is logged, so you can show an auditor exactly who approved what and when.
- It sits above the stack you already own, so nothing gets ripped out to make room.