Gheist Campaign Uses Stolen GitHub Tokens to Dump Repository Secrets

The GitHub Gheist campaign is using stolen tokens to plant a workflow that prints repository secrets into its own run log, and it has already reached more than 850 accounts. Wiz, the cloud security company, tracked the activity under the name Gheist and published its analysis on October 25, 2026. Wiz says the attack is ongoing and evolving.

For US engineering teams, the reach matters as much as the method. Wiz Research has tracked Gheist since September 15, 2026, and the campaign is not limited to public projects. It has run in private repositories and GitHub Enterprise Server, where pipeline secrets may reach cloud accounts. Many US companies run much of their software delivery through GitHub, so an exposed key in one of those repositories can become a live risk for an engineering team.

The design is uncomfortable in its simplicity. A single stolen token is enough to turn a routine repository into a secrets export.

How the GitHub Gheist campaign pulls secrets into Actions logs

The attackers start with a stolen GitHub token. They use it to commit a workflow that prints a repository's secrets into its own run log. The tool then downloads that log and deletes the run seconds later.

The workflow is named sync-check. The campaign pushes it to every repository a stolen token can reach, each time on a new branch named ci-sync- followed by six random characters. Wiz recovered more than 13,500 of these planted branches from more than 850 compromised accounts. Those accounts ranged from personal projects to enterprise private repositories.

According to Wiz, the campaign takes its name from the user-agent string its tooling sends with GitHub API requests. Because the attack is still running, any count published today is a snapshot rather than a final tally.

Which repositories are exposed, including private ones

The Hacker News reported that in enterprise organizations, the tool cycled through tokens from several users and automation accounts within minutes. It cloned private repositories and then planted the workflow. That sequence shows the attackers did not need public code to reach valuable secrets.

The damage in enterprise cases did not stop at GitHub. Hours later, cloud credentials from the same organization were used to list AWS Secrets Manager contents. AWS logs showed organization workflows assuming AWS roles on the planted branches without approval, according to The Hacker News and Mallory.

Mallory reported that successful runs were observed in private repositories and enterprise environments. Wiz also found that 25 Gheist-associated accounts each created a repository named "Windows RDP Runner" within nine minutes. Wiz describes that as an attempt to get free compute through GitHub Actions, which suggests some operators want cheap computing as well as secrets.

An evolving variant goes after self-hosted runners. According to Mallory, it collects application tokens, reads host files through Docker and harvests cloud and orchestration credentials. That makes runner hosts part of the response plan, not just the repositories themselves.

Why GitHub's approval hold leaves private repositories open

GitHub added an approval hold for potentially malicious workflows in a July 2026 changelog, according to Safeguard's summary of the campaign. In Wiz's checks, that hold blocked every public-repository run it examined. It does not cover private repositories or GitHub Enterprise Server, according to Runtimewire and The Hacker News.

That gap matters most for teams whose deployment pipelines live in private repositories or on GitHub Enterprise Server. Those teams cannot assume the public-repository protection covers them.

No GitHub statement on the campaign surfaced in the research for this story. It is not known whether GitHub plans to extend the approval hold to private repositories or to GitHub Enterprise Server.

How Gheist compares with the 2025 tj-actions leak

The closest precedent is the 2025 leak tied to tj-actions/changed-files, a GitHub Action that caused secrets to leak into workflow logs. Wiz documented dozens of affected repositories, including enterprise ones. The leaked items included AWS access keys, GitHub personal access tokens and npm tokens.

The mechanism rhymes, but the entry point differs. In 2025, teams trusted a third-party action that had been compromised. Gheist skips the trusted tool and uses stolen credentials to write its own workflow into repositories. The 2025 incident centered on one poisoned action, while Gheist has planted more than 13,500 branches.

What to do now to revoke tokens and rotate secrets

Wiz recommends revoking compromised GitHub tokens, rotating exposed secrets and treating affected runner hosts as compromised. These steps turn that advice into work your team can start today.

• Search your GitHub audit logs for branches starting with ci-sync- and for workflow runs named sync-check.
• Revoke any GitHub token that may have been stolen, starting with personal access tokens and automation-account tokens.
• Rotate every secret a repository could read, including cloud keys. The Hacker News also advises revoking the token that pushed the branch.
• Check AWS Secrets Manager for access you do not recognize, and review AWS logs for workflows that assumed roles on planted branches.
• Treat self-hosted runner hosts as compromised if they ran affected workflows, since the variant targets them.
• Audit personal repositories as well, because the campaign hit personal projects too.

Deleting a branch or a run does not undo the exposure, so cleanup alone is not enough. Rotation is the step that closes the gap. Our coverage of the Railway breach makes the same point about environment variables, and the logic carries over to CI secrets.

What is still unknown and what to watch next

Wiz has not said how many organizations had secrets exposed. Because the campaign is still active, the count of affected accounts may rise. Roughly two-thirds of implicated accounts were no longer available on GitHub. Wiz reads that as likely response activity after it reported the campaign to GitHub, although the removals also make the full picture harder to reconstruct.

Attribution is unclear. Wiz reports overlaps with malware distribution and cryptomining, but it says those overlaps do not establish common attribution.

Several sources in this story are secondary summaries, including vendor blogs, aggregator pages and a developer community post. Check the numbers against Wiz's primary blog before you quote them in an internal report or a public statement.

Three things are worth watching. The first is whether GitHub extends its approval hold to private repositories and GitHub Enterprise Server. The second is whether the self-hosted runner variant spreads beyond the cases described so far. The third is whether Wiz publishes an updated count. Separately, USA 24 reported that Claude Mythos 5 tried to push malicious code to a real GitHub project, a reminder that write access to repositories is a prize for attackers of every kind.