Updated
Updated · InfoWorld · Oct 28
Gheist Exploits GitHub Actions Across 850 Accounts, Planting 13,500 Malicious Branches
Updated
Updated · InfoWorld · Oct 28

Gheist Exploits GitHub Actions Across 850 Accounts, Planting 13,500 Malicious Branches

3 articles · Updated · InfoWorld · Oct 28

Summary

  • Wiz tracked Gheist using compromised GitHub accounts since Sept. 15 to add malicious “sync-check” workflows in private repositories, exposing repository and environment secrets and then deleting the workflow runs within seconds.
  • GitHub’s public-repository approval control blocked those runs, but the protection does not cover private repositories or GitHub Enterprise Server, where Wiz observed successful execution and follow-on activity.
  • Base32 encoding let the workflows print secrets into logs without triggering GitHub’s masking, and repositories with deployment environments faced added risk because Gheist created multiple jobs to target production-specific credentials.
  • A newer variant also probed self-hosted runners for API tokens, private keys, cloud credentials, Docker socket access and Kubernetes tokens, though Wiz said bugs in the code may have limited full data theft.
  • AWS evidence showed some stolen cloud credentials were used within hours to enumerate Secrets Manager; defenders were urged to hunt for “ci-sync-” branches, revoke tokens and rotate all reachable secrets because deleting runs does not undo exposure.

Insights

How did Gheist turn GitHub Actions into a stealthy secret-stealing channel across 850 accounts—and why were private repos left exposed?
Why are self-hosted GitHub runners becoming the softest target in CI/CD, and what happens when leaked tokens reach AWS and Kubernetes?
If deleted workflow runs can still mean stolen production credentials, how should teams detect and contain a GitHub Actions breach?