Gheist: 850 stolen GitHub tokens, and why agent tokens are the next target
Wiz Research published its write-up of Gheist on Sunday, a campaign it has tracked since September 15 that abuses compromised GitHub tokens at scale. Wiz counts "more than 13,500 planted branches from more than 850 compromised accounts." As of October 24, about two-thirds of the implicated accounts were no longer available on GitHub.
The pattern, at the level a defender needs: with a stolen token, the attacker commits a workflow to every repository the token can reach. The workflow exposes the repository's secrets in its own run log, the log is pulled through GitHub's API, and the run is deleted seconds later. Wiz points out two assumptions that fail here. GitHub's log masking only catches secrets that appear verbatim, so encoded values slip past. And restricting the job's own token permissions doesn't restrict access to the secrets themselves. Because everything leaves through GitHub's own API, there is no attacker domain to block. Wiz says a recent GitHub control stops this in public repos but not in private or enterprise ones.
Wiz doesn't claim agents are involved, and this isn't an AI attack. It's on this site because of who holds GitHub tokens now. Coding agents routinely run with a personal access token that can push branches and edit .github/workflows, often with access to every repo the human can reach. Last week's LiteLLM postmortem was the same shape: an agent platform holding an unscoped token from the org owner. One token is the whole attack surface.
The practical checklist is short. Give agents fine-grained, per-repo, short-lived tokens, never your personal one. Block agent writes to workflow files unless a human approves. Move secrets to environment-scoped ones with required reviewers. Then look in your org's audit log for a sync-check workflow or sudden branch creation across many repos. It's the same "credentials outside the agent" lesson the 1Password and Google agent-credential launches were selling last week, now with a live campaign attached.
Wiz write-up: https://www.wiz.io/blog/gheist-attempted-scaled-abuse-of-stolen-github-tokens-stumbles HN: https://news.ycombinator.com/item?id=50235010
← Back to all articles
The pattern, at the level a defender needs: with a stolen token, the attacker commits a workflow to every repository the token can reach. The workflow exposes the repository's secrets in its own run log, the log is pulled through GitHub's API, and the run is deleted seconds later. Wiz points out two assumptions that fail here. GitHub's log masking only catches secrets that appear verbatim, so encoded values slip past. And restricting the job's own token permissions doesn't restrict access to the secrets themselves. Because everything leaves through GitHub's own API, there is no attacker domain to block. Wiz says a recent GitHub control stops this in public repos but not in private or enterprise ones.
Wiz doesn't claim agents are involved, and this isn't an AI attack. It's on this site because of who holds GitHub tokens now. Coding agents routinely run with a personal access token that can push branches and edit .github/workflows, often with access to every repo the human can reach. Last week's LiteLLM postmortem was the same shape: an agent platform holding an unscoped token from the org owner. One token is the whole attack surface.
The practical checklist is short. Give agents fine-grained, per-repo, short-lived tokens, never your personal one. Block agent writes to workflow files unless a human approves. Move secrets to environment-scoped ones with required reviewers. Then look in your org's audit log for a sync-check workflow or sudden branch creation across many repos. It's the same "credentials outside the agent" lesson the 1Password and Google agent-credential launches were selling last week, now with a live campaign attached.
Wiz write-up: https://www.wiz.io/blog/gheist-attempted-scaled-abuse-of-stolen-github-tokens-stumbles HN: https://news.ycombinator.com/item?id=50235010
Comments