Gheist turns stolen GitHub tokens into secret dumps through Actions logs
Wiz reported on October 25 that the Gheist campaign used stolen GitHub tokens from infostealer logs and past supply-chain leaks to plant more than 13,500 ci-sync branches across 850+ accounts, printing every repository secret into Actions logs in base32 and deleting the runs.
Wiz said on October 25 that an automated campaign it calls Gheist had planted more than 13,500 branches from more than 850 compromised GitHub accounts, from personal projects to enterprise private repositories. The tokens trace to infostealer logs and to leaks from earlier supply-chain attacks such as the March Trivy compromise. For each repository a token can write to, the tool creates a ci-sync- branch with a single .github/workflows/sync-check.yml file and the message "ci: sync config". The workflow prints the job environment and every reachable secret in base32, which GitHub's log masking does not catch, then the tool downloads the log through the API and deletes the run within seconds. One version also runs a job per deployment environment to reach production secrets. GitHub's approval hold stopped public-repo runs, but Wiz reports successful runs in private repositories and on GitHub Enterprise Server.
Why it matters
Write access to a repository is read access to every secret its workflows can see, so a stolen developer token is effectively a stolen copy of production credentials. There is no attacker server to block: the secrets leave through GitHub's own API. In one enterprise, cloud credentials from the same organization were used against AWS Secrets Manager hours later.
Search for ci-sync- branches, runs deleted within a minute of finishing, and the gheist user agent in audit logs. Check cloud logs for role assumptions whose OIDC subject names a ci-sync- branch. If you find one, rotate every repository, organization and environment secret, revoke the pushing tokens, and check their owners for infostealer infections. Require reviewers on production environments, restrict OIDC trust to protected branches, and replace personal access tokens with GitHub Apps or short-lived fine-grained tokens. Compare the earlier GhostAction wave.
Source: Wiz
Related on Start with Identity
- BlogGhostAction phish completes a GitHub device flow, then hides a stealer in a font file
OpenSourceMalware found a fake GitHub security alert that proxied a maintainer's password and 2FA code, then silently completed an OAuth device flow for repo, w
- BlogLiteLLM traces its poisoned release to an admin key leaked in May and never revoked
LiteLLM's October 23 attack-chain report says an Agent Platform admin key committed to a public repo on May 27 was deleted but never revoked. On October 10 it r
- BlogCrowdSec kept a departing engineer's GitHub access open, and lost 170 private repositories through it
An engineer's laptop was infected in the May TanStack npm attack. Eleven days later his still-active GitHub OAuth token was used to copy about 170 of CrowdSec's
- CVEAuth0 node-jws HS256 verification bypass via secret lookup
node-jws before 3.2.3 / 4.0.1 can accept an HS256 JWT when the caller looks up the secret from attacker-controlled input. Medium on paper, but it is a signature
- ArticleB2B SaaS Security Tools: The Stack That Gets You Through Enterprise Procurement
The security tooling a B2B SaaS product actually needs to close enterprise deals in 2026, from enterprise SSO and SCIM to audit logs, secrets scanning, and acce
- CVEDuende OAuth token management mixes tokens across requests
A race in Duende's .NET OAuth token-management package could attach client A's token to client B's request. Session mix-up, not a crypto break, but it is still