Illustrative image: code on a developer's monitor. Image: Wikimedia Commons / Markus Spiske, CC0. This is not a screenshot of GitHub's systems or of the Gheist tool — a secrets-theft campaign has no product photo.
TL;DR — Gheist GitHub stolen tokens secrets explained in one line: since 15 September 2026, an automated campaign dubbed Gheist has used stolen GitHub tokens to plant secret-stealing workflows in more than 13,500 branches across 850+ accounts, and in private repositories the trick still works — GitHub's safeguard blocks it only in public repos. If a token you own touched a private repo, rotate every secret that repo could read.
📌 KEY HIGHLIGHTS
- The campaign: Gheist, named after the "gheist" user agent its tool sends with GitHub API requests, tracked by Wiz Research since 15 September 2026 and disclosed 26–27 October.
- The scale: 13,500+ planted branches recovered from 850+ compromised accounts, from personal projects to enterprise private repositories.
- The trick: a planted workflow prints the repo's secrets into its own run log, encoded in base32 so GitHub's masking misses them; the tool downloads the log, then deletes the run within seconds.
- The gap: a GitHub safeguard from July 2026 blocks the attack in public repositories — but not in private repositories or GitHub Enterprise Server, where Wiz saw the workflows actually run.
- The second variant: from 19 October, a "sync-host" job targets self-hosted runners, hunting 31 credential formats including cloud keys and AI-provider API keys.
- The honest limit: Wiz has not said how many organisations actually had secrets exposed — planted branches are not the same as stolen secrets.
Gheist GitHub Stolen Tokens Secrets Explained: What Happened?
Cloud security firm Wiz disclosed the campaign in research published 26 October 2026, and it has been covered since by The Hacker News, Dark Reading and Help Net Security. The picture is unusually complete for a campaign disclosure, because the attackers left a signature: every API request from their tool carries the user agent "gheist", which is how Wiz named and tracked it.
The campaign starts not with a vulnerability in GitHub, but with stolen credentials. Wiz says the tokens appear to come mainly from two sources: infostealer malware on developers' machines, and credentials exposed in earlier software supply-chain compromises. A GitHub token is a powerful thing to steal — it authorises whoever holds it to open repositories, read code and, crucially, push changes, exactly as the token's owner could.
Once the tool has a token, it walks through every repository that token can reach. In each one it creates a branch named ci-sync- followed by six random characters, and commits a workflow file at .github/workflows/sync-check.yml with the message "ci: sync config". The commit is unsigned but authored as the token's owner, so at a glance it looks like ordinary maintenance. Pushing the branch triggers GitHub Actions automatically — and that is the whole attack.
How Gheist Steals Secrets, Step by Step
The workflow does one job: it prints the repository's environment variables and secrets into its own run log. GitHub normally masks secret values in logs, but only when they appear exactly as stored. The workflow encodes each secret in base32 first, so the masking does not recognise it and the secret prints in full. Seconds after the job finishes, the tool downloads the log through GitHub's own API and deletes the run. Because the secrets leave through GitHub's API, there is no attacker server, domain or outbound connection for a security team to block.
| Step | What happens | Why it matters |
|---|---|---|
| 1. Token stolen | Infostealer malware or an earlier breach hands attackers a GitHub token | The token works exactly like its owner — no exploit needed |
| 2. Branch planted | Branch ci-sync-XXXXXX created in every reachable repo |
Looks like routine CI maintenance |
| 3. Workflow runs | sync-check.yml prints secrets, base32-encoded, into the run log |
Encoding defeats GitHub's log masking |
| 4. Log harvested, run deleted | Tool downloads the log via GitHub's API, then deletes the run | Evidence vanishes within seconds; no attacker domain to block |
| 5. Secrets reused | In enterprise cases, cloud credentials were later used to enumerate AWS Secrets Manager | One repo secret can unlock production cloud accounts |
Illustrative image: server racks in a data centre hall. Image: Wikimedia Commons / Florian Hirzinger, CC BY-SA 3.0. Stolen repo secrets can lead attackers to production cloud systems — the servers themselves were not part of this campaign.
Why Private Repos Are the Target
GitHub put a safeguard in place in July 2026 that pauses suspicious workflow runs, and Wiz found it stopped every public-repository run it checked. But that protection does not cover private repositories or GitHub Enterprise Server — and in those environments, Wiz saw the planted workflows finish and then be deleted by the gheist user agent. In enterprise organisations, the tool cycled through tokens from several users and automation accounts within minutes, cloned private repositories before planting the workflow, and hours later cloud credentials from the same organisation were used to enumerate AWS Secrets Manager. Wiz is careful about what that proves: it does not say where those cloud credentials came from or who used them.
A second variant, added 19 October, raises the stakes further. Its "sync-host" job targets self-hosted runners — the machines teams run themselves to execute Actions — searching the host filesystem, process environments and mounted Docker containers for 31 credential formats, including cloud metadata, Kubernetes tokens and API keys for AI providers such as Anthropic, Hugging Face, Groq and NVIDIA.
There is one piece of good news in the disclosure. About two-thirds of the implicated accounts are no longer on GitHub, which Wiz says likely indicates response activity after it reported the campaign to GitHub. But as of 24 October the campaign was still active and evolving, so the takedowns have not ended it.
Why It Matters for Developers — Including in India
India has one of the world's largest GitHub developer communities, and its startups and IT services firms run heavily on private repositories, self-hosted runners and cloud credentials stored as repo secrets. This campaign is aimed squarely at that setup: the secrets at risk in private repos are often environment-scoped credentials — production credentials, not demo keys. And the exposure does not end when you clean up: Wiz stresses that deleting the planted branch or the run does not undo the exposure, because the secrets were already printed into a downloaded log. Every secret the repository could read should be rotated, and the token that pushed the branch revoked.
The campaign also lands in the same week as GitHub's own agent-permission changes — our earlier coverage of GitHub Copilot assisted permissions — and the same threat landscape as the PHP2Shell flaws confirmed exploited by CISA. The common thread is automation turned against its owners: the tools that run your code can also be made to leak your keys. The CBFC data breach showed the same lesson on the government-portal side — documents sat exposed for days before anyone acted.
Should You Care?
✅ Verdict: Check your repos tonight, even if you think you are safe. If you hold a GitHub token — personal or automation — search your repositories for ci-sync- branches and sync-check.yml workflows, check audit logs for deleted runs, and rotate anything a hit repo could read. If you only use public repos, GitHub's safeguard is on your side, but a token reused anywhere private is still a live risk. ⏳ Do not stop at deleting the branch: deletion cleans the repo, not the exposure.
What to Do If You Are Affected
Work through this list in order — revoking first, rotating second, auditing third:
- Revoke the token that pushed the branch, and check whether the same token was used anywhere else.
- Rotate every secret the affected repository could read — not just the ones you think were printed. Include environment-scoped and production credentials.
- Search audit logs for runs on
ci-sync-branches and for runs deleted shortly after finishing, and check cloud logs (for example AWS CloudTrail) for unusual Secrets Manager enumeration. - Review self-hosted runners for the "sync-host" job and for unexpected Docker or filesystem access, and rotate keys those runners could reach.
- Tighten tokens going forward: fine-grained tokens with the minimum scopes, short expiry, no sharing between people and automation, and secret-scanning plus push protection switched on.
FAQs
What is the Gheist campaign?
Gheist is an automated campaign, tracked by Wiz Research since 15 September 2026, that uses stolen GitHub tokens to plant secret-stealing workflows in repositories. It is named after the "gheist" user agent its tool sends with GitHub API requests, and it has planted more than 13,500 branches across 850+ accounts.
How does Gheist steal GitHub secrets?
The tool creates a branch named ci-sync- plus six random characters and commits a workflow that prints the repo's secrets into its run log, encoded in base32 so GitHub's masking misses them. It then downloads the log through GitHub's API and deletes the run within seconds, leaving almost no trace.
Are public repositories affected by Gheist?
No, not in Wiz's checks: a GitHub safeguard from July 2026 pauses suspicious workflow runs in public repositories and stopped every public run Wiz examined. Private repositories and GitHub Enterprise Server are not covered by that safeguard, and that is where Wiz saw the workflows actually run.
How do I know if my repository was hit by Gheist?
Look for branches starting with ci-sync-, a workflow file at .github/workflows/sync-check.yml with the commit message "ci: sync config", and audit-log entries showing workflow runs that finished and were then deleted. Check cloud logs too — in enterprise cases, stolen credentials were later used against AWS Secrets Manager.
What should I do if my GitHub token was stolen?
Revoke the token immediately, then rotate every secret the affected repositories could read — deletion of the branch or run does not undo the exposure, because the secrets were already downloaded. Audit your logs, check self-hosted runners for the "sync-host" variant, and switch to fine-grained, short-lived tokens with minimum scopes.
Takeaway: Gheist turns GitHub's own automation into a secrets thief — 13,500+ planted branches, private repos still exposed, and deletion alone does not fix it. Check for ci-sync- branches, revoke, rotate everything, and tighten your tokens before the next variant arrives.
Follow World Tech on TechByCountry for tomorrow's update.
📸 Get tech in the last 24 hours on Instagram — follow @_techinlast24hrs for daily posts (9 AM–9 PM) and reels at 12:30 PM & 8:30 PM.
Sources
The Hacker News — Gheist Uses Stolen GitHub Tokens to Steal Private Repository Secrets via Actions Logs (26 Oct 2026)
Dark Reading — 'Gheist' Weaponizes GitHub Tokens to Steal Cloud Secrets (26 Oct 2026)
Help Net Security — Private repos still leak secrets to Gheist, a stolen GitHub token campaign (27 Oct 2026)
DevOps.com — Gheist Hackers Abuse GitHub Tokens to Steal Repository Secrets (27 Oct 2026)
MSSP Alert — GitHub repository campaign uses stolen tokens to harvest secrets (26 Oct 2026)
Comments
Post a Comment