Gheist: stolen GitHub tokens are dumping Actions secrets into workflow logs

What we know as of October 27, 2026, from Wiz Research's report published on October 25. We will update this post as more is disclosed.

Wiz Research has been tracking a campaign it calls Gheist since September 15. It takes GitHub tokens that have already been stolen and uses each one to plant a small workflow in every repository the token can reach. The workflow's only job is to print the repository's secrets into its own log, where the attacker reads them through GitHub's API before deleting the run seconds later. Wiz says it has recovered more than 13,500 planted branches from more than 850 compromised accounts, from personal projects to private repositories in enterprise organisations, and that the activity was still ongoing and evolving as of October 24.

It is worth understanding in detail, because nothing in it is exotic. It turns ordinary push access into access to every secret a repository's workflows can see.

How does the Gheist attack work?

For each repository, the tool creates a branch named ci-sync- followed by six random characters, and commits a workflow file, .github/workflows/sync-check.yml, with the message "ci: sync config". The commit is authored as the token's owner, so to GitHub it looks like that person pushed it. The push triggers the workflow, which dumps the runner's environment and the repository's secrets to the log, encoded in base32.

The encoding is the trick. As Wiz explains, GitHub masks a secret in a log only when the exact value appears. An encoded secret no longer matches, so it prints in full. Restricting the job's permissions doesn't help either: it limits what the job's own GITHUB_TOKEN can do, but not which secrets the job can read. Where a repository has deployment environments, a later variant runs the dump once per environment, which pulls out environment-scoped secrets too, and those are often production credentials. Because everything leaves through GitHub's own API, there is no suspicious domain or outbound connection for a firewall to catch.

Wiz also describes a second job, added on October 19, that targets repositories with self-hosted runners and searches the runner host itself for tokens, private keys, .env files, cloud instance credentials and Kubernetes service account tokens. Wiz notes that this job is buggy, but the intent is clear: a self-hosted runner reached this way should be treated as compromised.

Why didn't it work everywhere?

Since July 28, GitHub has held potentially malicious workflow runs in public repositories until a collaborator approves them. Wiz reports that every public Gheist run it checked was stuck waiting for that approval, so the payload never ran. That hold does not apply to private repositories or to GitHub Enterprise Server. There, Wiz found runs on ci-sync- branches completing and then being deleted, and in some organisations, hours later, cloud credentials from the same organisation being used to enumerate AWS Secrets Manager.

The tokens themselves came from somewhere else first. The sources Wiz could trace are infostealer logs and tokens exposed in earlier supply-chain compromises, and the same accounts turn up in other campaigns too. A stolen token rarely serves only one attacker.

What should you do now?

If your organisation uses GitHub Actions with private repositories, Wiz's report gives a clear checklist, and the essentials are short.

1. Hunt. Look for branches matching ci-sync- plus six characters whose only change adds sync-check.yml, for workflow runs on those branches deleted within a minute of finishing, and for the user agent gheist in your GitHub audit log. If your workflows reach the cloud through OIDC, look in your cloud audit logs for role assumptions whose subject includes a ci-sync- branch.
2. Respond. Rotate every repository, organisation and environment secret that an affected repository could reach. Deleting the branch or the run does not undo the exposure. Revoke the tokens that pushed the commits and check their owners' machines for infostealers.
3. Harden. Require reviewers on environments that hold production secrets, scope OIDC trust to protected branches or environments, and replace long-lived personal access tokens with GitHub Apps or short-lived fine-grained tokens.

What is the lesson for everyone else?

Gheist is a reminder that a secret stored in CI is only as private as the least protected token with push access to that repository. The secrets were not leaked by careless code; they were read by a workflow anyone with push rights could have written. Two habits limit the damage. The first is to keep high-value secrets behind something a pushed commit cannot reach on its own, such as required reviewers on environments or OIDC trust that only protected branches can use. The second is to keep secrets short-lived, so that what leaks expires before it can be reused.

Rotation is also the step that tends to go wrong under pressure. When you rotate a dozen secrets in an afternoon, the new values have to reach the people and systems that need them, and the quickest channel is usually a chat window. If you are handing replacement credentials to teammates or contractors, send them in a link that expires rather than as a message that stays in history. Our guide to sharing .env files with your team covers when you need a sync tool and when a one-off handoff is enough, and the secret zero problem covers the first credential every secrets manager still needs.

Updates: none yet.

---

Sources (checked on October 27, 2026):
Wiz Research: Gheist, attempted scaled abuse of stolen GitHub tokens (October 25, 2026) ·
GitHub: using secrets in GitHub Actions ·
GitHub: OpenID Connect in GitHub Actions

Product names are trademarks of their respective owners. CredenShare is not affiliated with them.