Summary
- More than 13,500 branches were planted through over 850 compromised accounts.
- Public repository approval controls interrupted observed suspicious workflow runs.
- Private and enterprise environments showed successful execution and subsequent cloud activity.
Attackers have used compromised GitHub accounts to plant malicious automation workflows across thousands of software repositories, with researchers finding that security controls blocked execution in public projects while some private and enterprise environments remained exposed.
The campaign, tracked as Gheist by Wiz, has operated since at least September 2026 and relies on valid but stolen developer access rather than exploitation of a newly identified vulnerability in GitHub itself.
Wiz researchers reported on 25 October that they had recovered more than 13,500 planted branches associated with over 850 compromised accounts. The affected identities included individual developers and contributors whose permissions extended to company-controlled repositories.
The attackers attempted to introduce GitHub Actions workflows capable of retrieving credentials accessible during automated builds and development tasks. Their access allowed them to create branches and submit workflow changes, but creating a branch does not mean the workflow necessarily executed.
A distinguishing feature of the operation was the use of automation logs to recover information from malicious runs. Investigators also observed efforts to delete workflow records, reducing what could be established from a repository's ordinary interface after an event.
GitHub introduced approval controls for suspicious workflow changes in public repositories in July. Those checks require a collaborator to approve certain runs before the platform will execute them, separating an ability to push a proposed change from permission to run that change with available secrets.
Wiz found that malicious public repository runs examined during its investigation were held at the approval stage. It did not observe those blocked public runs successfully executing, indicating that the control interrupted an important part of the campaign.
The situation was different in some private repositories and GitHub Enterprise Server environments. Researchers found successful workflow execution, deleted records and follow-on activity that could be examined through cloud audit logs.
In some cases, evidence showed organisational workflows running on attacker-created branches and assuming AWS roles. Such activity provides a route for investigating possible credential use even if the original GitHub run information has been removed.
The researchers distinguish planted workflows, execution and subsequent compromise as separate stages. The large count of planted branches is not a victim count, and a compromised developer account does not establish that every repository accessible to it suffered successful secret theft.
Wiz also reported overlap with other suspicious activity affecting some compromised accounts. Those observations do not prove that every associated operation was controlled by the same individuals, because stolen credentials may be transferred or reused by unrelated groups.
The investigation is distinct from the GhostAction campaign previously covered by Cyber Insider. Both involve malicious workflows and credential exposure, but the researchers identify different operational patterns and evidence.
GitHub repository permissions can reach well beyond code modification. Build systems may access software-signing credentials, cloud roles, deployment tokens and package registries, meaning that compromise of a developer identity can create opportunities within automated infrastructure.
That exposure depends on the permissions granted to each workflow, the availability of secrets during execution and the controls imposed by the repository owner. Restrictions applied to public projects may not automatically cover private installations or self-hosted systems.
The available evidence therefore points to several different investigative priorities: whether an account was compromised, whether an unauthorised branch was added, whether a workflow ran and whether accessible credentials were subsequently used. Each question demands different evidence.
Removing an unauthorised branch does not necessarily revoke a credential that a completed workflow could already have collected. Investigators may therefore need to examine cloud identity logs alongside GitHub records, especially where workflow history was deleted after execution. This distinction is grounded in the researchers' observations of subsequent cloud activity, rather than an assumption that every planted branch achieved secret theft.
Wiz said the campaign remained active and evolving in late October. Its findings show that repository approval controls successfully interrupted observed public runs, but that comparable protection was not uniformly present in privately administered development environments.
