The exfiltration channel was already inside your firewall rules
Cloud security firm Wiz has been tracking a campaign it calls Gheist since mid-September, and the mechanism is the kind of thing that makes a CISO reread their own egress rules. The attackers do not need malware, a command-and-control server, or any outbound connection a network team could spot. They need one stolen GitHub token with write access, because write access alone is enough to read every secret configured in a repository once a workflow is running inside it.
That single design fact inverts the usual defensive posture. Security teams spend heavily on detecting data leaving the network toward somewhere unexpected. Gheist's data never leaves toward anything unexpected, because the exfiltration channel is GitHub's own Actions logging infrastructure, a system every engineering organization already trusts and already has open. The attacker downloads the log through GitHub's own API, using the same access path a legitimate CI pipeline uses every day.
How a six-character branch name becomes a secret dump
The mechanics are almost mundane by design. For each repository the stolen token can reach, the tool creates a branch named ci-sync- followed by six random characters, then commits a single file, .github/workflows/sync-check.yml, with the message ci: sync config. Pushing that branch triggers the workflow, which prints the job's environment and every secret the job can read, encoded in base32. GitHub masks secrets in plain logs, but that masking does not survive a basic encoding trick, so the full values appear in the output undisguised.
One version of the tool goes further, running a separate job for each deployment environment configured in the repository, which exposes environment-scoped secrets that Wiz says are often production credentials rather than test keys. The attacker then pulls the log through the API and deletes the workflow run within roughly a minute of it finishing. Wiz's researchers put the implication plainly: deleting a branch, or the run it started, does not undo the exposure. The secrets were already read and copied before the cleanup ever ran.
The scale and the second-order damage
Wiz has recovered more than 13,500 planted branches across more than 850 compromised accounts, spanning everything from personal side projects to enterprise private repositories and GitHub Enterprise environments. The firm has not disclosed how many organizations actually had secrets exposed, only the footprint of the planting activity itself, which tells us this is closer to an automated sweep across every reachable account than a campaign aimed at a handful of specific targets.
The downstream activity is where this moves from alarming to operationally dangerous. In at least one organization, cloud credentials tied to the same account were used hours later to enumerate AWS Secrets Manager, and CloudTrail logs showed the organization's own workflows assuming AWS roles from the planted ci-sync branches, meaning Actions ran there without anyone approving it. Some victims were separately found running PolinRider, malware Wiz links to North Korea, suggesting the stolen tokens are being reused by more than one attacker group once they surface.
Why GitHub's own safeguard does not close the gap
GitHub introduced a hold on suspicious workflow runs in public repositories back in July, requiring manual approval before they execute, and Wiz confirmed that control stopped every Gheist attempt it checked on github.com's public repositories. That is a genuine win, and it shows the platform is capable of catching this exact pattern reliably once it has visibility into the behavior and a reason to flag it as suspicious before the workflow is allowed to run at all.
The hold does not extend to private repositories, where most production code and secrets actually live, and it does not cover GitHub Enterprise Server, the self-hosted product many larger organizations run specifically to keep source code off github.com's shared infrastructure. Enterprise customers who assumed that self-hosting bought them the same protections GitHub applies on its public platform turn out to be exactly the ones most exposed to this campaign, because the safeguard that stopped it elsewhere was never built to reach their environment in the first place.
What a security team can actually detect
Wiz's detection guidance is specific enough to act on today, and most of it can be scripted against existing log pipelines without buying a new tool. Look for branches matching the pattern ci-sync- followed by six lowercase alphanumeric characters, where the only change is the sync-check.yml file and the commit message reads ci: sync config. Check GitHub audit logs for runs on those branches that are deleted within a minute of finishing, and for any activity carrying the gheist user agent string in API requests, since that string shows up consistently across every variant of the tool Wiz has analyzed so far.
For organizations using OIDC-based cloud authentication, Wiz notes that cloud audit logs showing role assumptions with a ci-sync- branch name in the token subject will surface the activity even without pulling GitHub's own logs, which matters for teams whose GitHub log retention does not go back far enough to catch a campaign that has been running since mid-September. Rotating every secret a compromised repository could reach, and revoking the token that pushed the commit, are the only ways to actually close an exposure once it is found, and both steps need to happen before the organization moves on to figuring out how the token was stolen in the first place.
The governance decision this forces on CI/CD
The structural fix Wiz recommends amounts to a permissions model change rather than a tool purchase: require a reviewer on any deployment environment holding production secrets, so a job cannot read them until a human approves that specific run. Combine that with replacing long-lived personal access tokens with GitHub Apps or short-lived fine-grained tokens, and the blast radius of any single stolen credential shrinks dramatically, because there is no durable token left for an infostealer to find months later.
For a CTO weighing where to spend the next quarter's security budget, this campaign argues for treating CI/CD permissions with the same rigor as production cloud IAM rather than as a developer-experience convenience to be unwound slowly. Every repository running with broad, long-lived write access is a standing exfiltration channel waiting for a stolen token, and the attackers who found that path are not going to need a second invitation to use it again.
