A sophisticated and large-scale cyberattack campaign targeting GitHub repositories has been effectively disrupted by researchers, revealing a significant vulnerability in how automated workflows can be weaponized. Security firm Wiz, which identified and tracked the operation, reported that malicious actors had successfully planted secret-stealing workflows across more than 13,500 branches, utilizing stolen access tokens to compromise a vast array of projects ranging from personal coding efforts to sensitive private enterprise repositories.
The campaign, which the researchers have dubbed "Gheist," was first detected on September 15. In a detailed report published on October 25, Wiz confirmed that they had monitored the threat actors’ activities for several weeks, tracking the illicit activity across more than 850 compromised accounts. By leveraging the power of GitHub’s automation infrastructure, the attackers sought to harvest sensitive credentials, turning the platform’s legitimate productivity features into a potent tool for industrial espionage and credential theft.
The Origins of the Stolen Tokens
The backbone of the Gheist operation was a massive stockpile of stolen GitHub Personal Access Tokens (PATs) and other authentication secrets. According to Wiz, these tokens were likely harvested from a variety of sources, including previous supply chain compromises and widespread infostealer malware infections. One notable incident identified by researchers as a likely source of the initial token pool was the March compromise of the Trivy security scanner, a popular tool used for vulnerability detection.
The breadth of the impact suggests that the attackers were indiscriminate in their targeting. By using automated scripts to push malicious workflows to every repository reachable by the stolen tokens, the perpetrators aimed to maximize their yield of secrets. Beyond simple credential theft, some of the compromised accounts were also observed being repurposed for secondary malicious activities, including the distribution of malware and the unauthorized deployment of cryptomining software, which further complicates the remediation efforts for affected organizations.
Workflow Trick Meets GitHub Approval Hold
The methodology employed by the Gheist attackers was both efficient and stealthy. Upon gaining access to a repository, the actors would create a new branch and commit a custom GitHub Actions workflow file. This file was specifically crafted to print the repository’s environmental secrets—such as API keys, cloud provider credentials, and database passwords—into the workflow’s own execution log.
Once the sensitive information was exposed in the log, the attackers would use GitHub’s application programming interface (API) to programmatically download the logs containing the harvested data. To avoid detection and maintain a clean footprint, the attackers would then delete the workflow run only seconds after its execution, effectively bypassing the need for an external command-and-control (C2) server. By utilizing the platform’s own infrastructure to host and exfiltrate the data, the attackers created a "living off the land" scenario that made their activities exceptionally difficult to flag through traditional network-based security monitoring.
However, the campaign faced a significant hurdle in the form of a platform-wide security update implemented by GitHub on July 28. In an effort to mitigate the risk of automated workflow abuse, GitHub introduced a mechanism that places potentially malicious workflow runs in public repositories on "hold" until a human collaborator explicitly approves them. Wiz researchers noted that this protection proved highly effective in the public sphere; every public Gheist workflow run examined by the team remained stuck in an action_required state, successfully preventing the malicious code from executing and dumping the repository’s secrets.
This critical security control, however, does not extend to private repositories or self-hosted instances of GitHub Enterprise Server. In these more restricted environments, the researchers observed that the malicious workflows were able to complete their execution on attacker-created branches before the runs were purged, demonstrating that even with modern security guardrails, private and enterprise environments remain uniquely vulnerable to these types of automated attacks.
Private Repositories Remain Exposed to Exploitation
The danger posed to private enterprise organizations proved to be the most severe aspect of the Gheist campaign. In these environments, the attackers were not merely looking for random keys; they were systematically cycling through user and automation account tokens to clone private repositories and gain a deep understanding of the organization’s infrastructure.
Wiz observed a clear pattern of escalation following these infiltrations. In several instances, the attackers used the harvested cloud credentials to enumerate and explore Amazon Web Services’ (AWS) Secrets Manager, a service that stores highly sensitive enterprise credentials. The ability to pivot from a compromised GitHub account to a full-blown cloud environment compromise highlights the compounding risks inherent in modern software supply chains, where a single weak point—such as a developer’s local machine or a stored access token—can serve as the gateway to an organization’s entire production cloud footprint.
The attackers also demonstrated a level of technical iteration, running two distinct variants of their tools in parallel to maximize their reach. One variant was specifically configured to support deployment environments, which allowed the attackers to target environment-scoped secrets—credentials that are typically reserved for production environments and often hold higher privilege levels. Another variant featured a job designed to search self-hosted runners for credentials and sensitive files. While Wiz researchers characterized this specific job as "buggy" and potentially unstable, its existence underscores the attackers’ intent to move laterally within enterprise networks to find high-value targets.
As of October 24, the situation appeared to be stabilizing, with roughly two-thirds of the accounts identified as being involved in the campaign no longer active on the platform. Wiz attributed this decline to proactive response measures taken by GitHub following the disclosure of the campaign. Despite this progress, the researchers warned that the Gheist campaign remains ongoing and is continuing to evolve. The threat actors behind these operations have shown an ability to adapt their tactics in response to platform defenses, suggesting that the threat of token-based automation abuse is far from resolved.
The Gheist campaign serves as a sobering case study in the dual-use nature of modern developer tools. By turning legitimate automation features like GitHub Actions into a mechanism for credential theft, the attackers have exploited the very features designed to accelerate software delivery. While newer platform controls have successfully disrupted the most common avenues for this abuse in public repositories, the underlying risk—the reliance on persistent, high-privilege access tokens—remains a critical concern. For enterprises and individual developers alike, the event underscores the urgent need for robust credential rotation policies, the use of fine-grained access tokens, and a vigilant approach to monitoring automated processes within their CI/CD pipelines. As the digital landscape continues to rely on integrated automation, the ability of attackers to manipulate these systems will likely remain a persistent and evolving challenge for security professionals worldwide.
