Skip to content
TrustList
Security advisories

Gheist campaign uses stolen GitHub tokens to dump Actions secrets

Editorial

By TrustList Editorial

Wiz Research tracked more than 13,500 planted ci-sync branches from over 850 compromised accounts; GitHub's approval hold stops the workflows in public repositories but not in private ones or GitHub Enterprise Server.

About Gheist campaign uses stolen GitHub tokens to dump Actions secrets

Gheist campaign uses stolen GitHub tokens to dump Actions secrets

25 October 2026: A campaign Wiz Research calls Gheist has been using stolen GitHub tokens since 15 September to plant a workflow in every repository each token can reach and print the repository's secrets into the workflow log. As of 24 October, Wiz had recovered more than 13,500 planted branches from more than 850 compromised accounts, from personal projects to the private repositories of enterprise organisations. Roughly two thirds of the accounts are no longer available on GitHub, which Wiz reads as response activity after it reported the campaign.

Not yet independently verified. This rests on Wiz Research's own report of 25 October 2026. We have no statement from GitHub, and the account and branch counts are Wiz's figures as of 24 October. We will update this when it can be confirmed, and remove this note.

How the attack works

For each repository the tool creates a branch named ci-sync- plus six random characters and commits .github/workflows/sync-check.yml with the message "ci: sync config", unsigned and authored as the token's owner. The push triggers the workflow, which prints the environment and the whole secrets context encoded in base32. GitHub masks secrets in logs only when they appear verbatim, so the encoded values print in full. Where a repository has deployment environments, the tool runs a job per environment, so environment-scoped secrets, often production credentials, are dumped too. The tool then downloads the log through the GitHub API and deletes the run within seconds. Because the secrets leave through GitHub's own API, there is no attacker domain to block.

From 19 October one variant added a second job for repositories with self-hosted runners. It searches the host for 31 token formats, private keys, .env files, Terraform state and shell history, reads every process's environment, uses the Docker socket to search the host's root filesystem, and collects cloud instance credentials. Wiz notes that this job is buggy and misses some of what it looks for.

Where it works and where it does not

Since 28 July, GitHub has held potentially malicious workflow runs in public repositories until a collaborator approves them, and every public Gheist run Wiz checked was stuck at that hold. The hold does not apply to private repositories or GitHub Enterprise Server. There, audit logs showed runs on ci-sync branches completing and being deleted by the "gheist" user agent, and in enterprise organisations Wiz saw cloud credentials from the same organisation used hours later to enumerate AWS Secrets Manager.

The same compromised accounts appear in other activity: lure repositories distributing malware, attempts to use Actions for free compute, and victims also infected with PolinRider. Wiz traces the tokens to infostealer logs and to earlier supply-chain compromises.

What security teams should do

Wiz's advice:

  • look for ci-sync- branches whose only change adds .github/workflows/sync-check.yml, and in audit logs for runs deleted within a minute of finishing or any activity from the gheist user agent;
  • if workflows use OIDC to reach the cloud, check cloud audit logs for role assumptions whose subject includes a ci-sync- branch;
  • on self-hosted runners, look for the files .gdmp_pat, .gdmp_patg and .gdmp_sweep;
  • rotate every repository, organisation and environment secret available to an affected repository, since deleting the run does not undo the exposure, and revoke the tokens that pushed the commits;
  • do not approve held sync-check runs.

To harden, Wiz recommends required reviewers on environments with production secrets, OIDC trust policies scoped to protected branches, GitHub Apps or short-lived fine-grained tokens instead of personal access tokens, and ephemeral self-hosted runners without Docker socket access.

Related on TrustList:

Sources

Categories & features

TrustList Weekly

The week in software and IT, in one email

The news that matters to buyers, new rankings and our own research. Every Thursday, free, and easy to leave.

We will email you to confirm. Unsubscribe with one click in any issue. Privacy policy