An automated campaign called Gheist uses stolen GitHub tokens to plant workflows that print repository secrets, including private and GitHub Enterprise ones, into Actions logs. If your team uses GitHub with CI/CD, search your audit logs today for ci-sync- branches and, if you find any, rotate every secret.
The essentials
- Wiz has recovered more than 13,500 planted branches from more than 850 compromised accounts, ranging from personal projects to private enterprise repositories (The Hacker News).
- Each attack creates a
ci-sync-branch followed by six random characters and pushes a single file,.github/workflows/sync-check.yml, with the commit message “ci: sync config”. - Since 28 July GitHub holds potentially malicious runs until a collaborator with write access approves them, but only on public github.com repositories.
- Wiz has tracked the campaign since 15 September, said it was still active and evolving as of 24 October, and estimates it hit “a dozen companies” (Dark Reading).
How does it steal the secrets?
The attacker doesn't need to break anything. They use a stolen GitHub token, create the branch and push the workflow. That workflow prints the job environment and every secret it can read, encoded in base32. GitHub masks secrets in logs, but doesn't guarantee it once the value is encoded, so the full text comes out. The attacker then downloads the logs and deletes the run.
Because the secrets leave through GitHub itself, there is no attacker server and no outbound connection to block. Your firewall sees nothing unusual.
Where do the tokens come from? Wiz traced some of them to infostealer logs and to tokens exposed in earlier supply chain attacks, according to The Hacker News.
Am I affected if my repositories are private?
Yes, and more so than with public ones. GitHub's hold stopped every run on the public repositories Wiz checked, but it doesn't cover private repositories or GitHub Enterprise Server. The attacks have worked on private repositories and in GitHub Enterprise environments.
In enterprise organisations, the tool cycled through tokens from several users and automation accounts within minutes and cloned private repositories before planting the workflow. Hours later, cloud credentials from the same organisation were used to enumerate AWS Secrets Manager. The theft doesn't stay in GitHub.
Around 19 October a version appeared that launches a second job against self-hosted runners. Wiz describes it as broken and reports no successful execution.
What to do today
- Ask whoever runs your GitHub to search the audit logs for runs on
ci-sync-*branches deleted less than a minute after finishing, and for activity from the “gheist” user agent. - If your workflows use OIDC with your cloud provider, check its logs for role assumptions whose subject includes a
ci-sync-branch. - If you find any trace, rotate every repository, organisation and environment secret that repository could use: AWS or other cloud keys, deployment tokens, database passwords. Deleting the branch or the run does not undo the exposure.
- Revoke the tokens that made the commits and check their owners' laptops for infostealers.
- Keep a written record of the review, whether you find something or not.
What it means for a small business
The weak point here isn't GitHub: it's long-lived personal tokens. One old token with write access is enough to read every secret in the repository. At a startup, those secrets are often the production cloud keys.
Our view: treat this as a credential management problem, not a vendor problem. Over the medium term, replace personal tokens with GitHub Apps or short-lived tokens, require reviewers on production environments, restrict OIDC to protected branches or environments and use ephemeral self-hosted runners. None of these measures is exotic or expensive.
Don't forget GDPR. If a stolen secret gives access to personal data in production, it can become a notifiable breach. That's why you should document the review. If you want a second look at your CI/CD chain, you can lean on our cybersecurity service.
One caveat: these details come from specialist media citing Wiz's report. We haven't accessed the original report or a GitHub advisory.
Frequently asked questions
Is deleting the ci-sync branch enough?
No. The secrets have already left through the logs. You need to rotate all of them and revoke the tokens involved.
Will my firewall catch it?
Not through data exfiltration: the secrets leave through GitHub itself, with no connection to an attacker server. Detection relies on the audit logs.
Am I protected if I use GitHub Enterprise Server?
No. The run hold GitHub has applied since 28 July only covers public github.com repositories.
