Reducing the value of a stolen GitHub token

Gheist did not begin with a GitHub vulnerability. It began with tokens that could already do useful damage. Wiz traced credential sources to infostealer logs and earlier supply-chain exposures, including tokens linked to the March Trivy compromise. Once a token could write to a repository, the attacker could create a branch, commit a workflow, and use the repository's own runner to read secrets.

The defensive objective is not to make token theft impossible. It is to make a stolen token cheap to revoke, hard to reuse, and limited in what it can reach.

Replace broad personal credentials

GitHub recommends GitHub Apps or short-lived fine-grained tokens instead of long-lived personal access tokens. A GitHub App has fine-grained permissions and is not tied to a user account. A fine-grained token should have only the repositories and actions required for its task.

Inventory where personal access tokens are used for automation. Give each workload a distinct identity where possible. Remove repository, organization, package, workflow, and administrative scopes that the job does not use. Set expiration dates and make ownership visible.

The goal is practical containment. If a token used for a read-only release check is stolen, it should not be able to push arbitrary branches to production repositories.

Treat write access as secret access

GitHub's secure-use documentation states that anyone with write access to a repository has read access to all secrets configured in it. This is the link Gheist exploited. The token owner did not need to know a secret value. The workflow could read it at run time.

Review which roles can modify workflows and which repositories contain production secrets. Separate repositories with high-value deployment credentials from repositories that accept routine changes from a larger group. Require review for workflow changes where the platform supports it.

Use environment protection for secrets that should not be available to every workflow run. Required reviewers can stop a job before environment secrets are accessed. That control is most useful when the reviewer is independent from the author and when deployment branch rules prevent arbitrary branches from entering the environment.

Make misuse visible

Create alerts for new workflow files and unusual branch names. Record workflow creation, run start, run completion, log access, and run deletion. Retain the actor identity and source IP where available. Watch for the gheist user agent, but do not rely on one string.

Detect tokens that begin acting outside their usual repository pattern. A token that normally reads package metadata but suddenly pushes workflow changes should be treated as suspicious. A workflow that accesses the secrets context and writes encoded output deserves review even if the repository is private.

Cloud audit logs provide another detection surface. Search for OIDC role assumptions from unexpected branches or environments. Correlate the cloud action with the GitHub actor and time.

Use exposure data to prioritize the cleanup

ZoomEye returned 12,520 observations for app="GitHub Enterprise" with all asset types at the time of writing. This external inventory can identify GitHub Enterprise services whose repository and token controls should be reviewed first.

Open the GitHub Enterprise inventory.

The count is not a list of stolen tokens. It helps scope where an organization should verify ownership and control coverage. The token review still depends on GitHub settings, audit logs, and application registrations.

Respond before rotating blindly

When a token is implicated, revoke it first and preserve its metadata. Identify its repositories and the secrets they can read. Look for new branches, workflow files, repository settings, deploy keys, and app installations created after compromise. Check whether the token could grant access to other tokens or automation identities.

Rotate exposed secrets in dependency order and verify that the old values stop working. Then reduce the next token's reach. A clean inventory, short lifetimes, narrow scopes, and review on high-impact changes all make a repeat incident less productive for the attacker.

References

• Wiz Research: Gheist attempted scaled abuse of stolen GitHub tokens
• GitHub: Secrets
• GitHub: Secure use reference
• GitHub: Managing environments for deployment
• The Hacker News: Gheist uses stolen GitHub tokens