A repository intrusion can cross into cloud access
Wiz reported October 25 that an automated campaign it calls Gheist uses stolen GitHub tokens to plant workflows intended to expose repository secrets through workflow logs. The firm says it recovered more than 13,500 planted branches associated with more than 850 compromised accounts. Those account and branch counts are not a count of organizations with confirmed secret theft. Wiz reports successful exploitation in private repositories and enterprise environments, with activity still evolving as of October 24.
Public-repository protection has a boundary
GitHub’s July 28 announcement describes an automatic approval hold for workflows it identifies as potentially malicious in public repositories on github.com. The notice says the protection does not extend to GitHub Enterprise Server. Wiz says every public Gheist run it checked was held, while private-environment records showed completed runs and rapid deletion. The distinction matters for businesses whose most sensitive build configurations are private. A successful protection observed on a public project cannot simply be assumed to cover the company’s other repositories.
Bring the cloud owner into the investigation
Wiz also observed organizations’ own workflows assuming AWS roles from attacker-created branches. It recommends reviewing cloud audit records for role assumptions or token exchanges associated with the suspicious branches, alongside GitHub audit activity. Our analysis is that this creates a useful bridge between development and cloud-response teams. A manufacturer’s deployment pipeline or a media company’s publishing service may be operated by a different team from the repository administrator. Both owners need the same incident timeline. These are operational examples, not identified victims. Investigators should establish which workflows ran, what access was available and which cloud actions followed, without assuming every later action had the same origin.
Recovery extends beyond deleting a branch
Wiz advises affected organizations to rotate the repository, organization and environment secrets available to the repository and revoke the tokens used to push the malicious changes. Removing a branch or a run does not reverse an earlier disclosure. For the business owner, the recovery plan should therefore identify the services that depend on each credential and the order in which replacements can be introduced safely. Our recommendation is to retain evidence of both revocation and successful service restoration. For prevention, Wiz recommends production-environment reviewers and cloud identity trust restricted to protected branches or environments. Those restrictions deserve an explicit acceptance test: an unapproved branch should not inherit production authority merely because it belongs to a familiar repository. A quiet build dashboard is insufficient evidence that the boundary is enforced.
Sources & further reading
Our practical suggestions are editorial guidance. Verify applicability against current source and vendor instructions.
