Gheist: GitHub's 'Partial Win' Left Private Repositories Exposed

Since September 15, 2026, Wiz Research has tracked Gheist, a large-scale abuse campaign leveraging stolen GitHub tokens. The operation planted more than 13,500 branches across over 850 accounts — ranging from personal projects to private enterprise organization repositories — with the goal of exfiltrating secrets through malicious Actions workflows. The defining detail: the approval gate GitHub introduced on July 28, 2026, completely blocked execution on public repositories, but does not apply to private repositories or GitHub Enterprise Server environments, where runs completed successfully.

How the Bypass Exfiltrates Through GitHub APIs

The malicious workflow, dubbed "sync-check" by the source, establishes no external connections to attacker-controlled infrastructure. Instead, it exploits GitHub's own APIs: it prints secrets to the run log, downloads them via the API using the "gheist" user agent, and deletes the run to erase traces. According to Wiz Research, "because the secrets leave through GitHub's own API, there is no attacker domain or outbound connection to block."

The masking evasion hinges on base32 encoding. GitHub masks secret values only when they appear verbatim in the log; by transforming them into base32, the encoded value does not match the masking pattern and is printed in cleartext. The Tool B variant expands the attack surface with an environment matrix: it cycles through different deployment environments to extract secrets scoped to specific contexts, often production credentials.

The Mismatch Between Public Defense and Private Surface

On July 28, 2026, GitHub implemented an approval gate requiring explicit authorization before workflow execution on public repositories. For Gheist, the gate worked: "the malicious payloads never ran." But the same protection does not extend to private repositories or GitHub Enterprise Server environments, where the workflow executes automatically.

GitHub audit logs show executions on "ci-sync-*" branches that complete the cycle and are then deleted by the same "gheist" user agent. This mismatch creates a concentrated risk condition: private enterprise repositories typically host the most sensitive secrets — cloud credentials, service tokens, deployment keys — precisely where the defense is thinnest.

Collection on Self-Hosted Runners and Tool Limitations

An additional job, "sync-host," is designed to run on self-hosted runners and search for 31 token formats, including AI providers such as Anthropic, Hugging Face, Groq, and NVIDIA, as well as private keys, .env files, and Terraform state. However, the same job has implementation flaws: it looks for a runner file with the wrong name, uses a non-functional URL-credential regex, and does not collect GCP or Azure tokens. These flaws may have limited the extent of collection on self-hosted environments, though the source does not quantify the actual impact of this limitation.

Overlaps With Other Campaigns and Token Movement in the Ecosystem

The source documents concrete overlaps with at least four distinct activities. On October 6, 2026, 391 accounts renamed 1,461 repositories to "cracked-software" as bait (lure repositories), incidentally deleting 610 "ci-sync" branches. On October 18, 25 accounts created "Windows RDP Runner" repositories for cryptomining on Actions. Between October 19 and 20, three victims re-pushed Gheist commits containing a loader associated with PolinRider, a group attributed to North Korea. Finally, 57 accounts from the first Gheist phase had already been compromised by the May 2026 Megalodon campaign.

"This campaign is leveraging compromised GitHub access. The same accounts are used by other actors and campaigns, which demonstrates how compromised credentials can move throughout the threat actor ecosystem" — Wiz Research

Token sources include infostealer logs and prior supply-chain compromises, such as the March 2026 Trivy tool incident. Roughly two-thirds of the involved accounts are no longer available on GitHub, indicating response and remediation activity after the platform was notified.

What to Do Now

Organizations with private repositories or GitHub Enterprise Server should verify whether the workflow approval gate can be enabled in their environments, since the protection that blocked Gheist on public repositories does not automatically apply to these scopes. Audit logs must be checked for completed and subsequently deleted runs on "ci-sync-*" branches, a pattern indicating successful Gheist activity.

For secret masking, pipelines should implement additional controls that detect base32 encoding in run logs, because GitHub's verbatim filter does not catch this variant. Organizations using deployment environments with scoped secrets should review their access matrix: Gheist's Tool B variant explicitly cycles environments to extract production credentials.

On self-hosted runners, the "sync-host" job searches for 31 token formats including AI providers; verifying the presence of these tokens in cleartext on runners, even with the flawed tool, reduces the exposure surface. Finally, the overlap with Megalodon on 57 accounts indicates the compromised credential pool is shared: rotation of GitHub tokens must be prioritized for accounts already involved in prior campaigns.

Frequently Asked Questions

Does GitHub's approval gate protect private repositories as well?

No. According to Wiz Research, the gate active since July 28, 2026 applies to public repositories, while on private repositories and GitHub Enterprise Server the Gheist workflow runs completed successfully.

Does exfiltration occur through external attacker-controlled servers?

No. The tool downloads logs via GitHub's own APIs and deletes the runs. No outbound connections to attacker domains emerge that could be blocked at the network level.

Are Gheist and GhostAction the same campaign?

No. Wiz Research distinguishes them explicitly: GhostAction uses different workflow files and exfiltrates to IP 193.32.204[.]199, while Gheist operates through GitHub APIs with the "gheist" user agent.

Sources

• wiz.io
• threats.wiz.io
• threats.wiz.io