Gheist: a planted workflow dumps repo secrets, including AI provider keys

01What happened

Wiz Research published the Gheist campaign on 25 October 2026, after tracking it since 15 September. Rami McCarthy and Hila Ramati recovered more than 13,500 planted branches from more than 850 compromised GitHub accounts, ranging from personal projects to enterprise private repositories. Wiz says the campaign was still running and still changing on 24 October.

02How it works

The tool creates a branch named ci-sync- plus six random characters and commits a workflow file with the message ci: sync config. The payload base32-encodes the repository secrets so that GitHub's log masking does not catch them, and the operator then downloads the run log through the GitHub API and deletes the run. No command-and-control server is involved, because the secrets leave through GitHub's own API. A later variant adds a sync-host job that searches self-hosted runners for 31 token formats.

03Who is affected

Private repositories and GitHub Enterprise Server are where Wiz saw the attack succeed, because GitHub's automatic hold on suspicious workflow runs covers only public repositories on github.com. Organizations with self-hosted runners face the wider sweep, which hunts Anthropic, Hugging Face, Groq and NVIDIA keys alongside private keys, .env files, Terraform state and cloud metadata. Wiz states Gheist is distinct from GhostAction.

04What to do

Rotate every secret the affected repositories could reach, because deleting a run or a branch does not undo the exposure, and revoke the tokens that pushed the commits. Hunt for the branch pattern and the audit-log markers listed below, and treat any self-hosted runner that ran a ci-sync branch, along with its instance role, as compromised. Do not approve held sync-check runs.

Questions people ask

Am I affected by Gheist if my repositories are public?

Public repositories on github.com were protected during this campaign. GitHub has held workflow runs it flags as potentially malicious for collaborator approval since 28 July 2026, and Wiz found every public Gheist run sitting at action_required, so the payloads never ran. Private repositories and GitHub Enterprise Server do not get that hold, and Wiz observed successful exploitation there.

How do I check whether Gheist reached my repositories?

Gheist leaves several markers a defender can search. Look for branches matching ci-sync- plus six characters that carry a .github/workflows/sync-check.yml file committed with the message ci: sync config. GitHub audit logs show runs deleted within a minute of completing, or API requests with the user agent gheist. Cloud audit logs showing a role assumed from a ci-sync branch work even without GitHub logs.

Does Gheist steal AI provider keys?

Gheist hunts AI provider credentials on self-hosted runners. Wiz reports that the sync-host job, added for repositories with self-hosted runners, searches for 31 token formats, among them keys for Anthropic, Hugging Face, Groq and NVIDIA. The same job targets private keys, .env files, Terraform state, shell history, process environments, the Docker socket and cloud metadata. Wiz notes the job is buggy and does not collect GCP or Azure tokens.

How is Gheist different from GhostAction?

Wiz states that Gheist is distinct from GhostAction, the earlier campaign that scraped AI provider keys from hundreds of repositories. Gheist uses no command-and-control server at all: the secrets leave through GitHub's own API when the operator downloads and then deletes the workflow run log. Wiz also links Gheist accounts to separate activity, including cracked-software malware lures on 6 October and three PolinRider infections on 19 and 20 October.

Sources 2 links, all fetched

1. 1wiz.ioWiz Research
2. 2github.blogGitHub Actions Hold