GitHub Token Theft Exposes Private Repository Secrets

Wiz recovered more than 13,500 planted branches from more than 850 compromised accounts, a single campaign that printed private repository secrets into GitHub Actions logs and then erased its tracks.

Gheist's core technique: stolen tokens, ci-sync branches, and base32 exfiltration

Security company Wiz says an automated campaign it calls Gheist used stolen GitHub tokens to push a single-file workflow into reachable repositories. For each target the tool created a new branch named ci-sync- plus six random characters and committed .github/workflows/sync-check.yml with the message "ci: sync config." Pushing the commit started a workflow that enumerated the job environment and printed every secret available to that job, encoding values with base32 so they would appear unmasked in job logs. Because GitHub’s documentation allows any account with write access to read repository-configured secrets, a stolen token with write permissions was sufficient for the tool to extract secrets.

How the campaign hid its traces and why deletion did not help

After the workflow ran, the tool downloaded the Actions log through GitHub’s API and deleted the run seconds later. In private repositories and on GitHub Enterprise Server, Wiz found audit-log evidence of runs finishing and then being deleted by requests that used the gheist user agent. Deleting the ci-sync branch or removing the run does not undo the exposure; Wiz’s guidance is clear: every secret a repository could read should be rotated and the token that pushed the branch revoked.

What GitHub’s safeguard caught — and what it did not

GitHub introduced a safeguard on July 28 that holds workflow runs it flags as potentially malicious until a collaborator with write access approves them. Wiz reports that every Gheist run it checked in public repositories was held and therefore never executed. But GitHub’s hold, GitHub says, "currently applies to public repositories on github.com only" and does not apply to private repositories or GitHub Enterprise Server. That gap allowed Gheist to run successfully in private and enterprise environments where Wiz observed the campaign’s activity.

Scope, timeline, and linked activity traced by Wiz

Wiz has been tracking Gheist since September 15 and reported the campaign to GitHub. As of October 24 the campaign was still active and evolving. The company tied some stolen tokens to infostealer logs and to tokens exposed in previous supply-chain attacks, including the March compromise of the Trivy vulnerability scanner. In enterprise organizations Wiz observed rapid cycling through tokens from multiple users and automation accounts, cloning private repositories and later seeing those organizations’ own workflows assume AWS roles — CloudTrail evidence that short-lived GitHub Actions credentials were used to access cloud resources. Wiz’s analysis does not say where those cloud credentials originally came from or who used them.

Indicators, checks, and remediation steps published by Wiz

• Look for branches whose names match the pattern ^ci-sync-[0-9a-z]{6}$ where the only change is .github/workflows/sync-check.yml and the commit message ci: sync config.
• In GitHub audit logs, search for workflow runs on ci-sync-* branches that were deleted within a minute of finishing and for activity from the user agent gheist.
• If workflows sign in to cloud providers with OIDC, check cloud audit logs (for example AWS CloudTrail) for role assumptions or token exchanges whose subject includes a ci-sync- branch.
• On self-hosted runners look for the files .gdmp_pat, .gdmp_patg, .gdmp_sweep and the string "gdmp-pivot" in job logs; a version of the tool pushed an extra job targeting self-hosted runners beginning around October 19, written to search runner machines for many credential types (Wiz describes that job as buggy and reports no successful run).

Wiz’s published indicators also include the user agent gheist, specific strings such as toJSON(secrets) }}}}' | base32 -w 120, and multiple Git blob SHA values for known workflow versions: f3da2b8b357dcda02fd455d314be2a95007516a6 (plain workflow), d09535857a741bbb976bdc084a9a021713133291 (timeout version), 1dc5af9cce950aad1eb1546ecce8565b117540c4 (separator version), and c665b778b2d822453293003e7ca0bbb2cb08e39d (self-hosted job version).

What this means for technologists, enterprise owners, and GitHub administrators

• Technologists and security teams: rotate every repository, organization, and environment secret that could have been read by a compromised token; revoke the tokens that pushed ci-sync commits; and check devices for infostealers, because Wiz traced some tokens to infostealer logs.
• Enterprise owners and cloud teams: if a ci-sync branch ran on a self-hosted runner, treat the runner and its cloud instance role as compromised; review CloudTrail and OIDC role-assumption logs for subject strings that include ci-sync branches.
• GitHub administrators and platform operators: the public-repo hold caught Gheist runs on github.com, but private repositories and GitHub Enterprise Server were not covered; teams should consider limiting OIDC trust to protected branches or environments and require reviewers on environments that hold production secrets.

Wiz’s account of Gheist ties a simple, repeatable technique — stolen tokens plus a tiny workflow that encodes and prints secrets — to broad activity across personal projects and private enterprise repositories. The campaign’s persistence and the discovery of over 13,500 planted branches underscore that token theft remains a high-impact entry vector; rotate exposed secrets, revoke involved tokens, and follow the repository- and Audit-log checks Wiz has published to detect whether your code or cloud identities were touched.

https://thehackernews.com/2026/10/gheist-uses-stolen-github-tokens-to.html