Wiz Research flags Gheist GitHub workflow abuse affecting 850+ accounts

Key points

• Wiz Research linked the Gheist campaign to misuse of GitHub API and workflow features.
• The intruders reused stolen tokens, added branches, altered automation jobs, and pulled secrets out.
• The reported scope covers about 13.5k branches and more than 850 accounts.
• No CVE applies; defenders must focus on access, permissions, and audit logs.

On October 27, 2026, Wiz Research published findings on a campaign it calls Gheist, describing how attackers turned ordinary GitHub features into a path for credential misuse. The reported pattern begins with tokens that were not obtained legitimately, then moves through the GitHub API and automated workflow jobs to create branches and alter execution paths. The objective, according to the facts provided, was to reach secrets and use them beyond the repository where they originated.

More than 850 accounts and roughly 13,500 branches appear in the activity, which makes this less a single-repository incident and more a broad abuse of trusted developer automation. Private codebases were exposed, and stolen credentials were reused. No CVE is attached, which is important: there is no patchable software flaw to wait for. The weakness is in how legitimate access and workflow permissions can be chained together.

For K-12 IT teams, the lesson is that GitHub is not just source storage; it is an identity and automation platform. A token with broad scope can create branches, trigger jobs, and read secrets if those secrets are available to workflows. The Gheist findings show why repository protections, token hygiene, and workflow review need to be treated as one control set rather than separate chores.

Watch for unexpected branch creation, workflow file changes, and secret access from unfamiliar locations. Review OAuth apps and personal access tokens, reduce workflow permissions, and require approvals for changes to automation. Because no CVE exists, detection depends on audit logs and posture checks rather than vulnerability scanning.

What to do now

1. Audit GitHub personal access tokens, OAuth apps, and deploy keys; revoke unused or overbroad credentials and rotate any secret that may have been exposed.
2. Set workflow token permissions to least privilege, default to read-only where possible, and require review before workflow files can be changed.
3. Search GitHub audit logs for branch creation, workflow edits, and secret access around October 27, 2026; compare findings with expected automation.
4. Enable secret scanning and push protection, and move long-lived secrets into environment-scoped secrets with required reviewers.
5. Apply branch protection and rulesets to default and release branches; block force pushes and unauthorized changes to automation paths.
6. Review private repository access and third-party integrations; remove stale collaborators and limit organization-wide permissions.
7. Alert on anomalous API activity, unusual token use, and workflow injection patterns; investigate any secret reads from new locations.

Original source

Help Net Security