Security researchers have uncovered a large-scale automated operation that leverages stolen GitHub access tokens to infiltrate repositories and expose sensitive secrets through GitHub Actions workflows. Once deployed, the malicious workflows print repository secrets into Actions logs, which the attackers retrieve before erasing evidence by deleting the workflow runs. According to cloud security firm Wiz, the campaign has successfully targeted both private repositories and GitHub Enterprise environments.
While GitHub introduced protections that automatically pause suspicious workflow executions, those safeguards currently apply only to public repositories on GitHub.com. As a result, private repositories and GitHub Enterprise Server installations remain vulnerable to this attack technique.
At the center of the operation are malicious branches named in a predictable format: ci-sync-xxxxxx, where six randomly generated characters are appended to the prefix. Removing these branches or deleting associated workflow runs does not eliminate the risk because any exposed secrets may already have been harvested. Organizations are advised to rotate all potentially compromised credentials and revoke any tokens used to create the malicious branches.
Wiz has been tracking the threat activity since September 15, 2026, and has dubbed the campaign "Gheist", a name derived from the distinctive gheist user agent string used by the malware when interacting with GitHub's API.
Researchers identified more than 13,500 malicious branches spread across 850+ compromised GitHub accounts, affecting everything from individual developer projects to repositories belonging to major enterprise organizations. The exact number of organizations whose secrets were exposed remains unknown.
Evidence gathered from private repositories and GitHub Enterprise installations shows malicious workflow executions successfully completing before being swiftly removed. Audit logs indicate that these workflows were launched from the rogue ci-sync branches and subsequently deleted by requests associated with the gheist user agent. Further investigation revealed that legitimate workflows belonging to victim organizations were also executed on these branches, assuming AWS roles through GitHub Actions in the process. This strongly suggests that the malicious workflows were running without human approval.
In enterprise incidents, attackers were seen cycling through tokens belonging to multiple users and service accounts within minutes. The tool cloned private repositories before injecting the malicious workflow. In some cases, cloud credentials later linked to the same organizations were used to enumerate resources in AWS Secrets Manager, indicating possible follow-on cloud reconnaissance activity.
As of October 24, researchers observed that the campaign remained active and continued evolving. Roughly two-thirds of the compromised GitHub accounts associated with the operation had been removed or disabled, likely as part of GitHub's remediation efforts after Wiz reported the activity.
GitHub's own documentation notes that anyone possessing write access to a repository can potentially access repository secrets. Consequently, a stolen token with sufficient permissions is all an attacker needs to execute this attack.
For every repository accessible through a compromised token, the malware creates a branch using the ci-sync naming convention and commits a single workflow file:
.github/workflows/sync-check.yml
The associated commit carries the message:
ci: sync config
The commit is unsigned and is attributed to the owner of the stolen token. Simply pushing the branch automatically triggers workflow execution.
The malicious workflow is designed to dump environment variables and all accessible secrets. Before printing them to logs, it encodes the data using Base32. Although GitHub normally masks secrets appearing in workflow logs, encoding alters the values enough to bypass standard masking mechanisms, allowing the secrets to appear unobstructed.
Researchers also discovered that the workflow intentionally defines an empty permissions block. This effectively restricts the automatically generated GITHUB_TOKEN while still allowing the workflow to read repository secrets. Since the attackers do not require the GITHUB_TOKEN, limiting it has no impact on their objective.
A more advanced version of the tool targets deployment environments as well. It launches separate jobs for each configured deployment environment within a repository, enabling it to capture environment-specific secrets that often include highly sensitive production credentials.
After successfully collecting the data, the malware downloads the workflow logs directly through GitHub's API and then deletes the workflow execution within seconds. Because the exfiltration occurs entirely through GitHub's infrastructure, organizations cannot block it through traditional network monitoring or outbound traffic controls.
GitHub introduced a security feature on July 28, 2026, that places suspicious workflows into a review queue pending approval by a trusted collaborator. According to GitHub, however, this feature currently applies only to public repositories hosted on GitHub.com and is unavailable for GitHub Enterprise Server installations.
Wiz found that every observed Gheist workflow execution within public repositories was successfully stopped by this approval requirement, preventing the malicious payload from running. However, the protection depends on GitHub correctly identifying suspicious workflows.
Researchers contrasted Gheist with another campaign known as GhostAction, which also targeted GitHub workflows. While GhostAction successfully operated in public repositories until GitHub began blocking it on October 9, Wiz noted that Gheist uses different workflow files and infrastructure, making it a separate threat.
Around October 19, attackers expanded their operation by introducing a second-stage component specifically designed to target self-hosted GitHub runners. These runners are systems maintained by organizations to execute GitHub Actions jobs internally.
The self-hosted runner payload searches for a wide range of credentials, including:
- Personal access tokens
- Private keys
- Environment variables
- AWS instance role credentials
- Runner authentication files
- Kubernetes service account tokens
In total, researchers identified attempts to locate 31 different credential types. Although Wiz described the component as unstable and poorly implemented, no confirmed successful executions have been documented.
Analysis of stolen token sources suggests that many credentials originated from infostealer malware logs and prior software supply chain compromises. Researchers specifically highlighted exposure resulting from earlier attacks such as the March compromise of the Trivy vulnerability scanner.
The campaign also intersects with other ongoing threat operations. On October 6, approximately 391 compromised accounts renamed around 1,461 repositories to impersonate cracked software projects and distribute malware. During this activity, more than 610 Gheist branches were inadvertently removed.
Some affected accounts also showed traces of PolinRider, a malware family linked by researchers to North Korean threat activity. On October 19 and 20, three compromised accounts re-pushed previously deployed Gheist commits while adding a malicious loader to a vite.config.js file.
Researchers additionally found overlap with Megalodon, another secret-stealing GitHub campaign that compromised thousands of repositories earlier in 2026. At least 57 accounts targeted by Gheist had previously been impacted by Megalodon.
How Organizations Can Detect Gheist Activity
Security teams should investigate repositories for:
- Branches beginning with ci-sync- followed by six random characters.
- A newly created file named
.github/workflows/sync-check.yml. - Commit messages reading "ci: sync config."
- Workflow runs that execute and disappear within minutes.
- Audit log records associated with the gheist user agent.
- OIDC authentication events referencing ci-sync branches.
- Files named:
.gdmp_pat.gdmp_patg.gdmp_sweep
- Job log entries containing:
gdmp-pivot
Published indicators of compromise include:
- User Agent: gheist
- Branch Pattern:
^ci-sync-[0-9a-z]{6}$ - Commit Message: ci: sync config
- Workflow File:
.github/workflows/sync-check.yml - Base32 Secret-Dumping String:
toJSON(secrets) }}' | base32 -w 120 - Git Blob SHA (Standard):
f3da2b8b357dcda02fd455d314be2a95007516a6 - Git Blob SHA (Timeout Variant):
d09535857a741bbb976bdc084a9a021713133291 - Git Blob SHA (Separator Variant):
1dc5af9cce950aad1eb1546ecce8565b117540c4 - Git Blob SHA (Self-Hosted Runner Variant):
c665b778b2d822453293003e7ca0bbb2cb08e39d
Recommended Response Actions
Organizations discovering a suspicious ci-sync branch should immediately:
- Rotate all repository, organization, and environment secrets.
- Revoke compromised GitHub tokens.
- Examine impacted devices for infostealer infections.
- Treat any self-hosted runner that executed the workflow as compromised.
- Avoid approving pending
sync-checkworkflow runs. - Refrain from executing code originating from ci-sync branches.
To reduce future risk, Wiz recommends:
- Requiring approval workflows for production environments.
- Restricting OIDC trust relationships to protected branches.
- Replacing long-lived personal access tokens with GitHub Apps or short-lived fine-grained tokens.
- Running self-hosted runners as disposable systems with minimal privileges.
- Preventing unrestricted Docker socket access and limiting exposure to cloud metadata services.
These measures can significantly reduce the impact of stolen GitHub credentials and make future workflow-based secret theft campaigns far more difficult to execute.
Found this article interesting? Follow us on X(Twitter) ,Threads and FaceBook to read more exclusive content we post.
