Stolen GitHub tokens are dumping secrets from private repositories. Search for ci-sync branches today

A campaign called Gheist is using stolen GitHub tokens to push a small workflow into every repository a token can reach. The workflow prints the repository’s secrets into its own Actions log, the attackers download the log, and the run is deleted seconds later.

Wiz has tracked it since September 15 and recovered more than 13,500 planted branches from more than 850 compromised accounts. Public repositories were mostly protected by a new GitHub hold. Private repositories and GitHub Enterprise Server were not.

Gheist deletes its GitHub Actions runs seconds after they finish. If a ci-sync branch ran in your private repo, treat every secret it could read as gone.

The 5-Minute Cyber Brief

Don’t Miss the Policy Changes That Affect Security Decisions

Get the key CISA actions, new regulations, guidance, and risk shifts in a quick daily brief.

Email addressSend me tomorrow’s brief

By subscribing you agree to our Privacy Policy.

Free. Weekday mornings. 5 minutes or less.

Stolen GitHub tokens are planting ci-sync branches

For each repository, the tool creates a branch named ci-sync- plus six random characters and commits one file, .github/workflows/sync-check.yml, with the message ci: sync config. The push starts the workflow, which prints the job environment and the full secrets context encoded in base32. GitHub masks secrets only when they appear verbatim, so the encoded values print in full.

Where a repository has deployment environments, one version runs a job per environment, so environment-scoped secrets print too; Wiz says these are often production credentials. In enterprise organizations Wiz saw the tool cycle through several users’ and automation accounts’ tokens within minutes, clone private repositories, and hours later saw cloud credentials from the same organization used to enumerate AWS Secrets Manager. As of October 24 the campaign was still running.

Private repositories and GitHub Enterprise Server have no hold

Since July 28, GitHub has held potentially malicious workflow runs in public repositories until a collaborator approves them, and every public Gheist run Wiz checked was stuck waiting. GitHub says that hold does not apply to private repositories or to GitHub Enterprise Server. There, audit logs show the runs completing and then being deleted by the gheist user agent.

GitHub’s documentation says anyone with write access to a repository can read its configured secrets, so one stolen developer or bot token is enough. Wiz traced some tokens to infostealer logs and to earlier supply-chain attacks. Because the secrets leave through GitHub’s own API, there is no attacker domain to block.

Search for ci-sync branches, then rotate what they could read

• Search every organization for branches matching ci-sync- plus six characters whose only change adds .github/workflows/sync-check.yml.
• In the GitHub audit log, look for workflow runs on ci-sync-* branches deleted within a minute of finishing, and any request with the user agent gheist.
• If you find one, rotate every repository, organization and environment secret that repository could use, revoke the token that pushed the commit, and check its owner’s machine for an infostealer.
• Do not approve held sync-check runs, and require reviewers on environments that hold production secrets.

Details

• Campaign: Gheist (Wiz Research, October 25, 2026). No CVE; this is token abuse, not a GitHub bug.
• Indicators: user agent gheist; branch regex ^ci-sync-[0-9a-z]{6}$; commit message ci: sync config; workflow string toJSON(secrets) }}' | base32 -w 120.
• Self-hosted runner variant (from about October 19): files .gdmp_pat, .gdmp_patg, .gdmp_sweep and the string gdmp-pivot in job logs. Wiz says this job was buggy and saw no successful run.
• Workflow blob SHAs: f3da2b8b357dcda02fd455d314be2a95007516a6, d09535857a741bbb976bdc084a9a021713133291, 1dc5af9cce950aad1eb1546ecce8565b117540c4, c665b778b2d822453293003e7ca0bbb2cb08e39d.

Hunt / verify

• If workflows sign in to AWS, Azure or GCP with OIDC, search cloud audit logs for role assumptions whose subject includes ci-sync-. Wiz says this finds Gheist even without GitHub logs.
• In AWS CloudTrail, look for ListSecrets or GetSecretValue calls from GitHub Actions roles in the hours after an unexpected ci-sync run.
• Limit OIDC trust policies to protected branches or environments, and replace long-lived personal access tokens with GitHub Apps or short-lived fine-grained tokens.

Source: Wiz: Gheist indicators and hunting steps

Sources

• Wiz: Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbles
• The Hacker News: Gheist Uses Stolen GitHub Tokens to Steal Private Repository Secrets via Actions Logs
• GitHub Docs: Using secrets in GitHub Actions

George Bailey

George Bailey is the byline of the CyberExperts editorial desk, the team behind the CyberExperts Daily Brief. The desk covers vulnerabilities, breaches and security news from vendor advisories, CISA alerts and other primary sources, and links those sources in every story. Questions or corrections: [email protected].