Gheist Campaign Hijacks GitHub Actions to Steal Secrets From Private Repositories and Enterprise Environments
A large-scale credential theft campaign is exploiting compromised GitHub access tokens to inject malicious automation workflows into software repositories, exposing sensitive credentials through GitHub Actions logs while attempting to erase evidence of the intrusion. The operation, tracked as Gheist by cloud security company Wiz, has affected hundreds of GitHub accounts and demonstrated how legitimate continuous integration infrastructure can be turned into an effective mechanism for stealing secrets.
Researchers have identified more than 13,500 malicious branches across over 850 compromised accounts, including private repositories belonging to enterprise organizations. The campaign has been active since at least September 15, 2026, and continued evolving throughout October, with attackers introducing new techniques for accessing deployment credentials and targeting self-hosted runners.
The attacks exploit a particularly dangerous security assumption in modern development environments: a GitHub token with repository write permissions can become a pathway to secrets that were never intended to be directly accessible to the token holder. By creating and executing a malicious workflow, attackers can cause GitHub's own automation infrastructure to retrieve sensitive values and expose them through job output.
Unlike conventional credential exfiltration attacks, Gheist does not necessarily require an external command-and-control server or suspicious outbound network connection. The attackers retrieve stolen information directly through GitHub's APIs, making the malicious activity harder to identify using network monitoring alone.
The campaign also reveals an important disparity between GitHub's security protections for public and private repositories. A recently introduced safeguard prevented the malicious workflows from executing in the public repositories examined by Wiz, but equivalent protection was not available for private repositories and GitHub Enterprise Server environments, where investigators observed successful workflow execution.
Stolen GitHub Tokens Provide the Initial Access
The Gheist operation begins with compromised GitHub authentication tokens obtained through sources that include infostealer malware and earlier software supply chain attacks. Wiz identified connections to credentials exposed during the March 2026 compromise of the Trivy vulnerability scanner, although not every token used in the campaign could be traced to a specific source.
These tokens allow attackers to interact with repositories through authenticated GitHub API requests, avoiding the need to exploit a vulnerability in GitHub itself. The campaign relies on legitimate permissions granted to compromised accounts, particularly the ability to create branches and push workflow files.
That distinction is central to understanding the threat. GitHub Actions is designed to execute automation defined in repository workflow files, allowing developers to build software, run tests, publish packages, and deploy applications. When an attacker obtains sufficient repository write access, those same capabilities can be redirected toward unauthorized operations.
Wiz observed the attackers cycling through tokens belonging to multiple users and automation accounts within individual organizations. In some enterprise environments, the operation used several compromised identities within minutes, suggesting an automated process designed to maximize access before credentials could be revoked.
The attackers also cloned private repositories before deploying their malicious workflows. This behavior increased the potential exposure beyond secrets stored in GitHub Actions, since repository contents may include proprietary source code, configuration files, internal documentation, and information useful for subsequent attacks.
The campaign demonstrates why compromised developer credentials represent a particularly serious enterprise risk. A token that appears limited to source code management may indirectly provide access to cloud infrastructure, production deployment credentials, and other systems connected to the development pipeline.
Malicious Workflows Turn GitHub Actions Logs Into an Exfiltration Channel
For each accessible repository, the attackers create a new branch whose name begins with ci-sync- followed by six randomly generated characters. They then commit a workflow file at .github/workflows/sync-check.yml, using the seemingly routine commit message ci: sync config.
The naming convention is designed to resemble ordinary maintenance or synchronization activity. In a busy repository, a branch associated with CI configuration might initially appear less suspicious than an obviously malicious file or an unexpected executable.
Once the branch is pushed, GitHub Actions can execute the newly introduced workflow according to the repository's configuration and applicable security controls. The malicious job collects environment variables and secrets accessible to the workflow, then writes their values into the job logs.
A critical part of the attack involves encoding sensitive values before printing them. GitHub Actions attempts to mask known secrets in logs, but that protection does not reliably recognize values that have been transformed into a different representation. Gheist uses Base32 encoding to change the appearance of secrets, allowing the encoded information to appear in the output without matching the original values protected by GitHub's masking mechanism.
The attackers subsequently retrieve the workflow logs through GitHub's API and delete the corresponding workflow runs, often within seconds of execution. The deletion reduces the visibility of the activity in ordinary repository interfaces, although it does not necessarily eliminate audit records or other evidence available to administrators.
This approach is particularly effective because the sensitive information leaves through an authorized platform interface. Traditional data loss prevention controls that focus on connections to attacker-controlled domains may not detect the transfer, since the attacker downloads the logs from GitHub rather than receiving the secrets through an external endpoint.
The operation illustrates a broader problem in CI/CD security: logging systems intended to support debugging and operational transparency can become exfiltration mechanisms when untrusted workflows are permitted to access secrets.
Private Repositories and Enterprise Deployments Face Greater Exposure
GitHub introduced a protective mechanism on July 28, 2026, designed to hold certain suspicious workflow runs until a collaborator with write permissions approves their execution. The safeguard provides an additional barrier against malicious automation introduced through compromised credentials or unauthorized repository modifications.
However, GitHub's documentation indicates that the protection currently applies to public repositories hosted on GitHub.com and does not extend to private repositories or GitHub Enterprise Server.
According to Wiz, every public-repository Gheist workflow examined by researchers was held for approval and did not execute its malicious payload. The findings suggest that the safeguard was effective against the observed campaign in those environments, although its coverage depends on GitHub identifying a workflow as suspicious.
The situation was different in private repositories. Investigators observed malicious workflow runs completing successfully before being deleted, demonstrating that the attackers could execute automation and potentially retrieve sensitive information without the same approval barrier.
GitHub Enterprise Server environments also showed evidence of malicious workflow activity. These deployments are often used by organizations seeking greater control over source code management and development infrastructure, making them particularly sensitive targets.
The disparity creates an uncomfortable security outcome: repositories containing proprietary code and production credentials may lack a protective control available to public repositories.
The findings do not establish that every private repository was successfully compromised or that every malicious workflow obtained valuable credentials. Wiz has not disclosed a confirmed count of organizations whose secrets were exposed. Nevertheless, the observed execution of malicious workflows establishes that the attack chain can succeed under real enterprise conditions.
Deployment Environment Secrets Become a High-Value Target
As the campaign developed, the attackers introduced workflow variants designed to enumerate and access GitHub deployment environments. These environments are frequently used to separate credentials and configuration values associated with development, staging, and production systems.
A malicious workflow capable of executing in the context of a deployment environment may gain access to secrets unavailable to ordinary repository jobs. Depending on the organization's configuration, those values could include cloud deployment credentials, API tokens, signing material, or access keys associated with production infrastructure.
Wiz observed versions of the Gheist tooling that attempted to create a separate job for each environment defined in a repository. This expanded the scope of the attack beyond general repository secrets and targeted credentials associated with specific operational stages.
The effectiveness of this technique depends on environment protection rules. GitHub supports required reviewers, which can prevent jobs from accessing protected environment secrets until an authorized person approves the deployment.
Where those protections are absent, an attacker with repository write access may be able to initiate workflows that access sensitive environment credentials without additional human authorization.
The campaign demonstrates why storing secrets in a CI/CD platform does not automatically make them inaccessible to compromised developer accounts. Security depends on the permissions governing workflow creation, the conditions under which jobs can execute, and the approval mechanisms protecting sensitive environments.
Organizations that treat production secrets as protected solely because they are stored in GitHub Actions may therefore underestimate the risks associated with compromised repository write access.
Gheist Expands Its Attack Surface to Self-Hosted Runners
On October 19, researchers observed a new Gheist variant targeting self-hosted GitHub Actions runners. Unlike GitHub-hosted runners, which execute jobs on infrastructure managed by GitHub, self-hosted runners operate on machines controlled by the organization and may have access to internal networks, local files, and cloud credentials.
The new payload attempted to collect sensitive information directly from the runner environment. Its targets included private keys, process environment variables, Terraform state files, cloud instance credentials, GitHub and GitLab runner configuration files, and Kubernetes service account tokens. It also attempted to use the Docker socket to inspect the underlying host filesystem, a technique that can create serious security exposure when containerized jobs have excessive privileges.
Wiz identified 31 categories of tokens and credentials targeted by the script, including keys associated with cloud platforms and AI service providers. This expansion suggests that the attackers were seeking opportunities to move beyond GitHub repository secrets and into the infrastructure supporting enterprise development operations.
However, the researchers found implementation errors in the self-hosted runner payload and did not report a successful execution of that component. The finding is therefore evidence of an attempted expansion rather than confirmation that the new technique compromised runner hosts.
Even an unsuccessful payload is relevant to defenders because it reveals attacker intent. Self-hosted runners frequently operate with access to internal services and cloud environments, making them valuable targets for adversaries who have already compromised repository permissions.
Evidence of Follow-On Cloud Activity
Wiz observed activity suggesting that some compromised GitHub environments may have been used as stepping stones toward cloud infrastructure.
In one enterprise case, the attackers cycled through multiple compromised user and automation tokens, cloned private repositories, and introduced malicious workflows. Hours later, cloud credentials associated with the same organization were used to enumerate AWS Secrets Manager.
The researchers did not establish where those cloud credentials originated or who performed the subsequent activity. As a result, the evidence does not conclusively prove that Gheist obtained the credentials through its malicious workflows. Nevertheless, the sequence demonstrates the potential relationship between compromised CI/CD infrastructure and broader cloud security incidents.
GitHub Actions commonly integrates with cloud providers through stored credentials or OpenID Connect (OIDC) federation. OIDC allows workflows to request short-lived credentials based on their identity and execution context, reducing reliance on long-lived cloud access keys.
However, OIDC does not automatically eliminate the risk of malicious workflow execution. If a cloud provider's trust policy allows an unprotected branch to assume a privileged role, an attacker who can create and execute workflows may obtain temporary access without stealing a permanent credential.
Wiz found evidence in AWS CloudTrail of workflows associated with attacker-created branches assuming cloud roles. This is especially important because cloud audit logs may preserve evidence of malicious activity even when GitHub workflow runs have been deleted.
For organizations investigating possible exposure, correlating GitHub audit records with cloud identity events can reveal activity that would otherwise be difficult to reconstruct.
Multiple Criminal Campaigns Exploit the Same Compromised Accounts
The Gheist investigation also revealed overlapping malicious activity involving accounts used by other campaigns. This suggests that compromised GitHub credentials circulate among multiple threat actors and can be reused for different objectives.
On October 6, researchers observed 391 accounts being used to rename approximately 1,461 repositories to resemble cracked software or other potentially attractive downloads. The operation appeared intended to distribute malware through repositories designed to attract unsuspecting users.
The activity overlapped with accounts affected by Gheist, although Wiz did not establish that the same operators controlled both campaigns. In fact, the researchers identified accounts involved in the repository-renaming operation that had not appeared in Gheist activity, suggesting a broader pool of compromised credentials.
Additional overlaps involved PolinRider, malware associated by researchers with North Korean activity, and Megalodon, an earlier campaign that targeted GitHub repositories with malicious secret-stealing workflows.
These connections should not be interpreted as proof that Gheist itself is operated by North Korean actors or by the groups responsible for the other campaigns. Shared compromised accounts may reflect credential resale, common infostealer sources, or independent exploitation of the same exposed tokens.
The broader pattern demonstrates how a single credential compromise can generate multiple security incidents over time. A token stolen by infostealer malware may later be used for repository manipulation, secret theft, malware distribution, or unauthorized computing workloads.
Revoking compromised credentials promptly is therefore essential, even when the original incident appears limited in scope.
Detecting Gheist in GitHub and Cloud Audit Logs
The campaign leaves several recognizable artifacts that organizations can use to investigate potential exposure.
<text weight="medium">Key indicators of compromise</text>
Indicator
Observed value
GitHub API user agent
gheist
Branch naming pattern
^ci-sync-[0-9a-z]{6}$
Malicious workflow
.github/workflows/sync-check.yml
Commit message
ci: sync config
Secret exfiltration technique
Base32-encoded workflow output
Runner artifacts
.gdmp_pat
,
.gdmp_patg
,
.gdmp_sweep
Runner log marker
gdmp-pivot
Wiz recommends investigating workflow runs on suspicious branches, particularly those deleted shortly after execution. Security teams should also review GitHub audit logs for the gheist user agent and examine unexpected workflow modifications committed by accounts that normally do not manage CI/CD configuration.
Cloud audit logs provide an additional detection opportunity. Organizations using OIDC federation should search for role assumptions or token exchanges associated with unexpected ci-sync- branches. Such activity may indicate that an attacker-controlled workflow obtained cloud permissions even when the corresponding GitHub logs are unavailable.
For self-hosted runners, the investigation should include filesystem artifacts, unexpected processes, access to credential stores, and attempts to interact with cloud metadata endpoints or Docker sockets.
The presence of a malicious branch should be treated as evidence of compromised repository access. However, determining whether secrets were actually exposed requires establishing whe