Gheist is an automated attack campaign that turns stolen GitHub tokens into a machine for stealing the secrets stored in software repositories. Wiz Research, which disclosed the campaign on 25 October 2026, recovered more than 13,500 planted branches across more than 850 compromised accounts, from personal projects to private enterprise repositories. It did not break into GitHub itself: it used valid, stolen tokens to plant a workflow that printed each repository’s secrets into its own build log, then downloaded the log and deleted the run seconds later.

The campaign has been running since at least 15 September 2026 and was still active and evolving as of 24 October, according to Wiz. Its name comes from the user agent, gheist, that the attackers’ tool sends on its GitHub API requests. This explainer sets out how Gheist works, why GitHub’s safety net stopped it in public repositories but not private ones, and how to check whether you were affected.

How does the Gheist attack work?

The attack is a chain of ordinary GitHub features used in a malicious order. No software flaw is exploited and no malware needs to land on a developer’s laptop. The steps, as documented by Wiz Research, are:

The base32 encoding is the clever part. GitHub normally masks known secret values in logs, so printing a secret directly would show asterisks. By encoding the output first, the attackers made the secrets look like meaningless text, which GitHub’s masking did not catch. The two commands in the workflow print the environment and then the whole secrets context in base32.

Where did the stolen tokens come from?

Wiz traced the tokens to two main sources: logs stolen by infostealer malware, which harvests credentials from infected computers, and credentials exposed in earlier software supply-chain compromises. One source the researchers cited specifically is the March 2026 compromise of the Trivy vulnerability scanner ecosystem, although not every token used in the campaign could be traced to a specific leak.

That matters because it shows the attack did not start with GitHub at all. It started with credentials stolen elsewhere, then reused against GitHub. A token with write access to repositories is, in effect, a key to everything those repositories can reach — including cloud keys, package-registry tokens and AI provider keys stored as repository secrets.

Why did GitHub’s safety net not stop it?

On 28 July 2026, GitHub introduced a control that holds potentially malicious workflow runs in public repositories until a collaborator with write access reviews and approves them. That control worked: Wiz found that every public-repository Gheist run it examined, across all variants, sat in the action_required state, so the malicious payload never ran.

The gap is that the control applies to public repositories on github.com only. It does not cover private repositories or GitHub Enterprise Server, and that is where the researchers saw the attack succeed: completed runs, deleted logs, private repositories cloned, and stolen cloud credentials used hours later to enumerate AWS Secrets Manager. In other words, the protection covered the repositories where the secrets are least sensitive, and not the ones where production credentials usually live.

What did the attackers actually steal?

The scale of planting is large — more than 13,500 branches and more than 850 accounts — but planting is not the same as stealing. In public repositories, the attack failed. In private repositories and GitHub Enterprise Server environments, Wiz observed completed workflow runs and follow-on activity, including private repositories being cloned and cloud credentials being used to probe AWS Secrets Manager. The researchers were careful to note that these findings do not mean secrets were stolen from every identified branch, only that the mechanism worked where the approval hold did not apply.

From 19 October, the campaign evolved further. A second job was added to the workflow, targeting self-hosted runners — the build machines some organisations run themselves — and hunting for cloud metadata credentials, Docker sockets and Kubernetes tokens. Self-hosted runners are a particular risk because they often sit inside an organisation’s own network, close to production systems.

Gheist vs GhostAction: what is the difference?

Gheist is often mentioned alongside GhostAction, a separate campaign reported by StepSecurity on 8 October 2026, in which attackers used two compromised maintainer accounts to push a malicious workflow to 345 repositories. The two campaigns share a technique — abusing GitHub Actions to steal secrets — but they are distinct operations with different workflow files, different infrastructure and different exfiltration methods. GhostAction sent stolen data to an attacker-controlled server; Gheist exfiltrated through GitHub’s own API, downloading its own run logs. Wiz says it does not attribute Gheist to any known actor.

How to check whether you were affected

If you own or administer GitHub repositories, check these indicators, all published by Wiz Research:

• Branches: search your repositories for branches starting with ci-sync- that you did not create.
• Workflow files: look for .github/workflows/sync-check.yml, especially with the commit message ci: sync config.
• Audit logs: search GitHub audit logs for the gheist user agent, and for unexpected workflow runs that were created and deleted within seconds.
• Self-hosted runners: check for the second job added from 19 October, which probes cloud metadata, Docker sockets and Kubernetes tokens.
• Cloud accounts: review AWS and other cloud audit logs for unusual Secrets Manager enumeration or role assumptions from the same period.

If you find any of these, treat every secret the affected repositories could reach as exposed: revoke the token, rotate the secrets, and check the cloud accounts they unlock. As of 24 October, roughly two-thirds of the implicated accounts were no longer available on GitHub, which Wiz said likely reflected response activity after it reported the campaign to GitHub — but the researchers said the attack was ongoing and continuing to evolve.

How to make a stolen token useless next time

Gheist works because a single token with broad write access is enough to reach everything. The defences are therefore about shrinking what a token can do. Use fine-grained personal access tokens limited to the repositories and permissions actually needed, give them short expiry dates, and never store a token with write access in a place infostealer malware can reach. Require approval for workflow runs from first-time contributors, audit who can approve them, and treat self-hosted runners as production systems: isolate them from cloud credentials, rotate their secrets, and monitor their logs. Finally, keep an inventory of which secrets each repository can reach, so that when a token is compromised you know exactly what to rotate.

Frequently asked questions

Was GitHub hacked? No. There is no report of GitHub’s own infrastructure being breached. The attackers used stolen tokens, which are valid credentials, to abuse ordinary platform features.

Is there a CVE for Gheist? No. Gheist is a campaign, not a software vulnerability, so there is no CVE number and no patch to install. The fix is credential hygiene, not an update.

Are my public repositories safe? Public repositories were protected by GitHub’s approval hold introduced on 28 July 2026: every public Gheist run Wiz checked was held and never executed. Private repositories and GitHub Enterprise Server were not covered, so check those first.

What should I do first? Search your GitHub audit logs for the gheist user agent and for branches starting with ci-sync-. If you find anything, revoke the token and rotate every secret the affected repositories could reach.

How is Gheist different from GhostAction? They are separate campaigns. GhostAction, reported on 8 October, hit 345 repositories through compromised maintainer accounts and exfiltrated data to an attacker server. Gheist is larger, uses different workflow files, and exfiltrates by downloading GitHub’s own run logs.

Sources: Wiz Research (25 October 2026) and Infosecurity Magazine (26 October 2026). Indicators and figures are as published by Wiz Research.