A large-scale cyberattack is abusing stolen GitHub access tokens to expose sensitive credentials stored in software repositories, including private projects and enterprise environments.
The campaign, tracked by cloud security firm Wiz as Gheist, uses malicious GitHub Actions workflows to extract secrets, download them through GitHub’s own API and delete the workflow runs to conceal the activity.
Wiz has tracked the campaign since September 15 and says it recovered more than 13,500 malicious branches linked to over 850 compromised GitHub accounts. The affected accounts range from individual developers to enterprise organizations. As of October 24, the campaign was still active and evolving, although roughly two-thirds of the identified accounts were no longer available on GitHub.
The attackers use stolen tokens to create branches with names beginning with ci-sync-, followed by six random characters. They then add a malicious workflow file named .github/workflows/sync-check.yml with the commit message ci: sync config. Creating the branch triggers GitHub Actions, which executes the workflow and attempts to expose secrets accessible to the repository.
The workflow prints environment variables and repository secrets after encoding them in base32. GitHub normally masks recognized secret values in workflow logs, but this protection can fail when the values are encoded or modified. The attackers subsequently download the logs through GitHub’s API and delete the workflow runs within seconds, making the activity harder to identify during routine investigations.
The campaign’s effectiveness comes from its use of legitimate GitHub functionality and compromised credentials rather than a conventional external server. Because the stolen information is retrieved through GitHub itself, blocking a suspicious external domain or outbound network connection may not stop the attack. Restricting the workflow’s GITHUB_TOKEN permissions also does not prevent it from accessing secrets made available to the job.
Wiz found evidence that the attacks succeeded against private repositories and GitHub Enterprise Server environments. In enterprise organizations, the attackers cycled through tokens belonging to multiple users and automation accounts within minutes and cloned private repositories before planting malicious workflows. CloudTrail records also showed organizational workflows running on the suspicious branches and assuming AWS roles. Hours later, cloud credentials associated with the same organizations were used to enumerate AWS Secrets Manager. Wiz did not establish precisely how those cloud credentials were obtained or who used them.
GitHub introduced a safeguard on July 28, 2026, that holds certain potentially malicious workflow runs in public repositories until a collaborator with write access approves them. Wiz reported that every public-repository Gheist run it examined remained blocked from execution. However, the protection currently applies only to public repositories on GitHub.com and is not available for GitHub Enterprise Server. Private repositories are also outside its coverage, leaving those environments exposed to this particular attack technique.
The attackers have continued modifying their tools. Around October 19, one version added a second job designed to run on self-hosted GitHub Actions runners, which are machines managed by organizations rather than GitHub. The job attempts to search the runner for credentials, private keys, environment variables, cloud access tokens, Kubernetes service account tokens and other sensitive files. It also attempts to use the Docker socket to access the host filesystem. Wiz identified bugs in this component and reported no successful execution of the job, but organizations should not assume their runners are safe if suspicious workflows have already run on them.
The investigation also found overlap between the compromised accounts and other malicious activity. On October 6, 391 accounts, many of which were also associated with Gheist, renamed approximately 1,461 repositories to make them appear to distribute cracked software. Those changes incidentally removed 610 of the malicious branches. Some affected accounts also showed signs of PolinRider malware activity, while 57 accounts from Gheist’s first phase had previously been targeted by the Megalodon campaign. Wiz says Gheist is distinct from GhostAction, another campaign involving malicious GitHub Actions workflows.
The sources of the stolen tokens include infostealer logs and credentials exposed during earlier supply-chain attacks, including the March 2026 compromise of the Trivy vulnerability scanner. The findings highlight how credentials stolen from one developer or automation account can expose multiple repositories and potentially provide access to an organization’s cloud infrastructure.
Wiz recommends that security teams search for suspicious branches matching the ci-sync- naming pattern, particularly those containing a newly added sync-check.yml workflow and the commit message ci: sync config. Administrators should also review GitHub audit logs for workflow runs that finish and are deleted shortly afterward, along with activity associated with the gheist user agent.
Organizations using OpenID Connect (OIDC) to authenticate GitHub Actions workflows with cloud providers should examine cloud audit logs for role assumptions involving suspicious ci-sync- branches. Teams operating self-hosted runners should also investigate the files .gdmp_pat, .gdmp_patg and .gdmp_sweep, as well as the string gdmp-pivot in job logs.
If a repository is affected, administrators should revoke the tokens used to introduce the malicious commits and rotate every repository, organization and deployment-environment secret that the affected workflows could access. Deleting a suspicious branch or workflow run does not reverse an exposure that has already occurred. Any self-hosted runner that executed a malicious job should be treated as potentially compromised.
To reduce future risks, Wiz recommends using GitHub Apps or short-lived, fine-grained tokens instead of broadly scoped personal access tokens, requiring reviewers for environments containing production secrets, and restricting cloud OIDC trust policies to approved branches or environments. Self-hosted runners should also be configured as short-lived machines with restricted access to Docker sockets and cloud metadata services.
If this article helped you, please consider supporting our work. Every small contribution keeps Abijita.com independent and running.
The Gheist campaign demonstrates how attackers can turn stolen developer credentials into a wider supply-chain security problem. Even when a malicious workflow disappears quickly, the credentials it exposed may remain usable until organizations revoke or rotate them.
Gheist Campaign Uses Stolen GitHub Tokens to Steal Secrets From Private Repositories
