The build log is the loot

Most secret theft needs a way out: a server to send the data to, a domain a defender can block. Gheist does not have one, and that is the design. A stolen GitHub token plants a workflow called `sync-check` in every repository it can reach. The workflow prints the repository's secrets into its own run log, encoded in base32 so GitHub's masking — which only hides a secret when it appears exactly as stored — does not catch it. The operator then downloads the log through GitHub's API, the same way a developer checks why a build failed, and deletes the run seconds later.

The scale Wiz recovered is more than 13,500 planted branches across more than 850 compromised accounts, from personal projects to private enterprise repositories. Read that number carefully. A planted branch is an attempt planted, not a secret confirmed stolen. Wiz's own headline says the campaign "stumbles", and the stumbling is part of the story. In the public repositories Wiz examined, the campaign's workflow runs were consistently stopped before execution. Every public Gheist run the researchers checked remained at `action_required`, meaning the payloads did not run.

A control that worked, where it applies

On July 28 GitHub began holding workflow runs it flags as potentially malicious in public repositories until a collaborator approves them. Every public Gheist run Wiz checked sits in that held state. The payloads never ran. That is a platform control doing exactly what it was built for, and it deserves to be reported as plainly as the failure next to it.

The hold applies to public repositories on github.com only. It does not apply to private repositories or GitHub Enterprise Server. There, Wiz found GitHub audit-log records of runs on ci-sync-* branches completing and then being deleted by the gheist user agent. CloudTrail records also showed organizations' workflows assuming AWS roles from those branches, evidence that GitHub Actions had executed without the approval step. In enterprise cases, Wiz observed private repositories being cloned before workflows were planted, multiple user and automation tokens being cycled within minutes, and subsequent use of cloud credentials to enumerate AWS Secrets Manager. These findings establish execution and follow-on access; they should not be read as proof that every planted branch successfully exposed secrets.

The pattern is familiar and worth naming. The protection covers the repositories whose secrets are usually least valuable, and stops at the boundary of the repositories where production credentials actually live. That is not an argument that the hold is worthless. It is an argument that a team reading "GitHub now blocks this" and stopping there has misunderstood its own exposure.

What to hunt for, today

This is one of the rare campaign reports that gives defenders a short, specific checklist. Some indicators are visible in GitHub audit logs; others can be found in cloud audit logs, even where GitHub logs are unavailable.

Look for branches named `ci-sync-` followed by six characters whose only change is a new `.github/workflows/sync-check.yml` committed as `ci: sync config`. In audit logs, look for workflow runs on those branches deleted within a minute of completing, and for any activity carrying the user agent `gheist`. If workflows authenticate to a cloud account with OIDC, check the cloud logs for role assumptions whose subject names a `ci-sync-` branch — that shows Actions ran on an attacker branch even when the GitHub run itself is gone. On self-hosted runners, look for the files `.gdmp_pat`, `.gdmp_patg` and `.gdmp_sweep`, and the string `gdmp-pivot` in job logs.

If a branch matches, Wiz's response list is equally plain: rotate every repository, organization and environment secret that repository could reach, because deleting the run or the branch does not undo an exposure; revoke the tokens that pushed the commits and check their owners' machines for infostealers; and if a `ci-sync` branch ran on a self-hosted runner, treat that host and its instance role as compromised. Do not approve a held `sync-check` run, and do not run code from those branches.

Where the report limits itself

Wiz is a security vendor reporting on a campaign its own product detects, and the piece closes with its detection rules. That does not invalidate the artifacts, which are specific and checkable in any organization's own logs, but it does mean the framing is Wiz's. Two of its own qualifications matter more than the headline count. First, recovered branches are not confirmed exfiltrations: the public ones demonstrably never ran, and Wiz does not claim a secret was taken from every private branch either. Second, the self-hosted runner variant — the part that searches a machine for AI provider keys, private keys and cloud metadata — is, in Wiz's words, buggy: a wrong key filename, a broken regex, and cloud token collection that does not work for two of the three clouds it targets.

What survives those qualifications is still actionable this week. A token stolen by an infostealer or leaked in an earlier supply-chain compromise can be turned, automatically, into a pass at every secret in every repository it touches, using only GitHub's own features. The one control shown to stop it works in public. Whether it has run in private is a question each organization can answer from its own audit logs in an afternoon.

Sources

  1. [1] Wiz Research, "Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbles", October 25, 2026 (primary — read first-hand: the 13,500+ planted branches across 850+ compromised accounts, the ci-sync- branch and sync-check workflow artifacts, the base32 masking bypass, exfiltration through the workflow log via GitHub's API, every public run checked held at action_required, completed and deleted runs in private repositories and GitHub Enterprise Server, the enterprise token-cycling and AWS Secrets Manager follow-on, the sync-host self-hosted variant and its bugs, the credential sources, and the hunt, respond and indicators lists)Read source
  2. [2] GitHub Changelog, "GitHub Actions holds potentially malicious workflows for approval", July 28, 2026 (the approval hold; states the protection currently applies to public repositories on github.com only)Read source
  3. [3] CSO Online, "Gheist turns GitHub Actions into a secret extraction service", Oct 2026 (independent account of the Wiz findings, including the self-hosted runner variant)Read source
  4. [4] Infosecurity Magazine, "Gheist Attackers Stumble in Attempt to Abuse GitHub Tokens", October 26, 2026Read source
  5. [5] AI News Brief, October 30, 2026 briefing (listed Gheist as an "ACT" item for October 30: scan GitHub orgs for `ci-sync-*` branches and `sync-check` workflows)Read source