Gheist Campaign Uses Stolen GitHub Tokens to Mass-Harvest Repository Secrets

Cloud security company Wiz has been tracking an automated attack campaign, which it named Gheist, that uses stolen GitHub access tokens to systematically extract secrets from private repositories and enterprise GitHub environments. Wiz has recovered more than 13,500 malicious branches planted across over 850 compromised accounts since it began tracking the campaign on September 15, 2026, and as of October 24 the operation was still active and evolving.

The name comes from the user agent string, "gheist," that the attackers' automated tool sends with every GitHub API request, according to the report published October 26 by The Hacker News.

How the Attack Extracts Secrets Without a Command Server

Gheist's mechanism is built to leave attackers with nothing to block. Using a stolen token, the tool enumerates every repository that token can access. For each one, it creates a branch with a name like ci-sync- followed by six random characters, then commits a single file — .github/workflows/sync-check.yml — with the innocuous commit message "ci: sync config." The commit is left unsigned.

Pushing that branch automatically triggers the workflow, which simply prints every environment variable and secret the job has permission to read. To get around GitHub's automatic log masking of known secret patterns, the tool encodes the output in base32 before printing it. The attacker then downloads the resulting log through GitHub's own API — meaning the stolen data never has to leave through an external server that a defender could detect or block — and deletes the workflow run within seconds of retrieving it.

Some variants of the tool go further, running a separate job for each deployment environment configured in the repository, which exposes environment-scoped secrets that frequently hold production-level credentials. Around October 19, Wiz observed a newer version attempting to add a job targeting self-hosted runners, searching the underlying machine directly for credentials — though Wiz describes this variant as buggy, with no successful run observed yet.

Scale and Real-World Consequences

Wiz has not disclosed how many organizations had secrets actually exposed, but confirms the campaign has succeeded against both private repositories and full GitHub Enterprise Server deployments — not just public, personal projects. In one enterprise case Wiz investigated, the tool cycled through stolen tokens belonging to several different human users and automation accounts within minutes of each other; hours later, cloud credentials tied to that same organization were used to enumerate its AWS Secrets Manager, though Wiz has not determined whether those cloud credentials originated from the same Gheist intrusion.

The stolen GitHub tokens being used appear to come from multiple sources, including infostealer malware logs circulating on criminal markets and leftover access from earlier supply-chain incidents, including the March 2026 compromise of the Trivy security scanner.

GitHub's Existing Safeguard Only Covers Half the Problem

Since July 28, GitHub has required a collaborator with write access to manually approve workflow runs flagged as suspicious — a change that Wiz confirmed stopped every Gheist attempt it tested against public repositories. However, that approval requirement does not extend to private repositories or to GitHub Enterprise Server, which is exactly where Gheist has had its documented successes.

Wiz also connects some of the compromised accounts to unrelated, concurrent abuse: on October 6, 391 accounts controlled by other actors renamed roughly 1,461 repositories to impersonate cracked software downloads, and some infected systems in the campaign also showed signs of PolinRider, malware researchers have linked to North Korean operators, as well as overlap with the separate Megalodon campaign from May.

Recommended Response

Wiz recommends organizations search their audit logs for branches matching the ci-sync- naming pattern and review any OIDC role assumptions tied to those branches. Any secret accessible to an affected repository should be treated as compromised and rotated immediately, along with revoking the stolen tokens themselves. Self-hosted runners that executed a ci-sync workflow should be treated as fully compromised machines, not just cleaned and reused. Longer term, Wiz recommends requiring reviewer approval specifically on production deployment environments, tightly scoping OIDC trust policies, and replacing long-lived personal access tokens with GitHub Apps or short-lived tokens wherever CI/CD pipelines allow it.