Wiz Says Gheist Campaign Uses Stolen GitHub Tokens to Print Repository Secrets Into Actions Logs, Succeeding in Private Repositories

Overview

Wiz Research says an automated campaign it calls Gheist is using stolen GitHub tokens to plant workflows that print a repository’s secrets into its own GitHub Actions logs, according to Wiz’s analysis published October 25. Wiz says it has tracked the activity since September 15, 2026, and that it recovered more than 13,500 planted branches from more than 850 compromised accounts, “ranging from personal projects to enterprise organizations’ private repositories.” Wiz also says the campaign gets its name from the user agent gheist carried by the tool’s API requests. The Hacker News reported on the findings on October 26.

How the attack works

For each repository a token can reach, 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, according to Wiz. The commit is unsigned and authored as the token’s owner, and the push event triggers the workflow. The workflow runs env | base32 -w 120 and echoes toJSON(secrets) through the same encoder, which Wiz says works for three reasons:

• “GitHub masks secret values in logs only when they appear verbatim. A base32-encoded secret doesn’t match, so it prints in full.”
• The workflow sets permissions: {}, which Wiz says restricts the job’s GITHUB_TOKEN (which the attacker does not need) but does not restrict the secrets context.
• When a repository has deployment environments, the tool lists them in a job matrix, so environment-scoped secrets, which Wiz says are often production credentials, print as well.

The tool then downloads the log through the GitHub API and deletes the run seconds later. Because the secrets leave through GitHub’s own API, Wiz says, there is no attacker domain or outbound connection to block.

GitHub’s documentation on secure use of Actions describes the underlying behavior: “Because there are multiple ways a secret value can be transformed, automatic redaction is not guaranteed.” It also states: “Any user with write access to your repository has read access to all secrets configured in your repository.”

Where GitHub’s safeguard applies

GitHub’s changelog from July 28, 2026 says Actions now holds certain workflow runs identified as potentially malicious until “a repository collaborator with write access reviews and approves it.” The changelog says: “This protection currently applies to public repositories on github.com only.” It adds that GitHub Enterprise Server does not have the protection at this time.

Wiz says every public Gheist run it checked, across all variants, sits at action_required: “The control worked, and the malicious payloads never ran.” In private repositories and on GitHub Enterprise Server, Wiz says, GitHub audit logs show runs on ci-sync-* branches completing and then being deleted by the gheist user agent. It adds that AWS CloudTrail shows the organizations’ own workflows running on those branches and assuming AWS roles, which Wiz says proves Actions executed without approval.

In enterprise organizations, Wiz says it saw the tool cycle through the tokens of several users and automation accounts within minutes and clone private repositories before planting the workflow. It also says that hours later, cloud credentials from the same organization were used to enumerate AWS Secrets Manager. The Hacker News notes that Wiz’s analysis does not say where those credentials came from or who used them, and does not say how many organizations had secrets exposed.

An evolving payload

Wiz describes two variants running in parallel. Tool A uses a hexadecimal branch suffix and the plain payload; Tool B uses a base36 suffix and, per Wiz, added timeout-minutes: 6 and the environment matrix within hours of its first run on September 28. On October 19, Wiz says, Tool B pushed a second job with runs-on: self-hosted, apparently only to repositories with a registered self-hosted runner. Wiz says the job searches for 31 token formats, private keys, .env files, Terraform state and shell history, and describes it as buggy. The Hacker News reports that Wiz’s analysis shows no successful run of that job.

As of October 24, Wiz says, the attack was ongoing and evolving, and roughly two-thirds of the implicated accounts were no longer available on GitHub, which Wiz says likely indicates response activity after it reported the campaign to GitHub.

Overlaps with other campaigns

Wiz reports that the same accounts are used by other actors. On October 6, it says, 391 accounts renamed about 1,461 repositories to cracked-software lures, wiping 610 ci-sync branches as a side effect. Wiz says 57 accounts from Gheist’s first phase were also victims of Megalodon in May, and that some victims appear to be infected with PolinRider, which it describes as DPRK-linked malware. As for where the tokens came from, Wiz says the sources it could trace were infostealer logs and tokens exposed in earlier supply-chain compromises such as the Trivy compromise in March.

Wiz states that Gheist is distinct from GhostAction, which uses different workflow files. The Machine Herald previously reported on a GhostAction wave.

What Wiz recommends

Wiz advises hunting for ci-sync- branches whose only change is the sync-check.yml file, and for ci-sync-* runs deleted within a minute of completing or any activity from the gheist user agent. For responding, it says to rotate every repository, organization and environment secret available to an affected repository: “Deleting the run or the branch doesn’t undo the exposure.” It also advises revoking the tokens that pushed the commits and treating a host as compromised if a ci-sync branch ran on a self-hosted runner. Hardening advice includes requiring reviewers on environments with production secrets, scoping OIDC trust policies to protected branches or environments, and using GitHub Apps or short-lived fine-grained tokens instead of personal access tokens.

What We Don’t Know

Wiz’s published analysis does not state how many organizations had secrets exposed, who operates the campaign, or where the credentials used against AWS Secrets Manager originated, according to the sources above. The campaign was still changing as of October 24.