The Daily Inference
AI & Technology · News · Developing

Attackers Hid Secret Leaks in 13,500 GitHub Branches, Wiz Says

GitHub's approval checks blocked the public workflow runs Wiz examined, but the security firm reports successful execution in private repositories and enterprise environments.

Developing: this story is still unfolding and details may change.

Attackers used stolen GitHub credentials to plant automated jobs designed to expose software secrets across thousands of branches, with some private-repository jobs succeeding, according to security firm Wiz. [1]

Wiz Research said it recovered more than 13,500 planted branches linked to more than 850 compromised accounts in a campaign it calls Gheist. Its investigation covered personal projects and private repositories inside enterprise organizations. [1]

The attackers' entry point was an access token, a credential that lets software act with a user's permissions. One stolen token can reach several projects, giving the attacker a way to plant the same malicious automation across every repository the credential permits. [1]

Wiz said GitHub's approval hold stopped every public-repository run it checked. But the firm also found evidence of completed, subsequently deleted runs in private repositories and GitHub Enterprise environments. Cloud audit logs, records of activity in cloud services, showed workflows on attacker-created branches using AWS roles, sets of cloud permissions that a workflow can borrow to reach cloud resources. [1]

The campaign was still changing as of October 24, according to Wiz, which published its investigation on October 25. The branch and account totals are the firm's findings, not a public incident count confirmed by GitHub. The number of repositories whose secrets were exposed, retrieved or used has not been established, nor has the route by which the attackers obtained the tokens. [1]

Turning an automation job into a leak

GitHub Actions runs automated tasks for software projects. Developers use it to build, test and deploy code, and those jobs may need credentials stored as secrets. Gheist tried to turn that routine access into a way to extract them. [1]

According to Wiz, the campaign created branches beginning with ci-sync-, followed by six characters. It added a workflow file at .github/workflows/sync-check.yml, using the commit message ci: sync config. Those ordinary-looking labels are now useful search terms for defenders. [1]

The workflow was designed to print repository secrets into its own execution log. GitHub masks secret values when they appear verbatim, so the attackers encoded them in base32, a reversible way to represent the same data using different characters. That changed their appearance enough to bypass the masking, Wiz said. [1]

The tool then retrieved the log through GitHub's application programming interface, the service software uses to interact with the platform, and deleted the run. The retrieval step required neither an attacker-controlled domain nor a separate outbound connection, according to Wiz. [1]

That gives defenders a harder task than searching for traffic to a suspicious website. The extraction route used GitHub's own service, while deleting the run could remove a conspicuous trace from the repository. Audit records become especially valuable in that sequence.

Some variants also listed deployment environments, which let organizations separate settings and credentials for different uses, such as testing and production. Naming those environments in the workflow could make their secrets available to the job too, Wiz said. [1]

The potential reach therefore depended on more than the code a token could edit. It also depended on the credentials an automated job could access after that edit.

A public safeguard with a defined boundary

GitHub announced its approval hold on July 28, 2026. It said certain potentially malicious Actions runs in public repositories would be paused until a collaborator with write access approved them. The protection applies to public repositories on github.com and excludes GitHub Enterprise Server. [2]

Wiz said the public Gheist runs it examined stayed in action_required, waiting for approval rather than executing. That is a concrete success for a safeguard that interrupts automation before it can use the permissions available to it. [1]

Private repositories showed a different outcome. Wiz cited GitHub audit logs recording completed runs that were then deleted, alongside cloud audit evidence of workflows assuming AWS roles. The public-repository hold did not apply to those private and enterprise cases, according to the firm. [1]

Within enterprise organizations, Wiz said the tool moved through tokens belonging to several users and automation accounts within minutes. It cloned private repositories before planting workflows. Cloud credentials from the same organization were later used to enumerate AWS Secrets Manager, which stores credentials and other sensitive values. [1]

That sequence extends the concern beyond a compromised developer account. Repository access can lead to automation access, which can lead to cloud access. Each set of permissions determines how far the intrusion can travel.

A later variant tried to add another step, running a second job on self-hosted runners, the organization's own computers used to execute Actions jobs. It sought credentials and sensitive files on those machines, but Wiz found bugs, including a search for the wrong runner key file and failures to collect Google Cloud or Azure tokens. Those attempted capabilities are not evidence that the host-level theft succeeded. [1]

What account owners should check

Wiz recommends looking for the ci-sync- branches, the sync-check.yml workflow and the ci: sync config commit message. Organizations should also inspect short-lived workflow runs deleted soon after completion and search audit logs for the gheist user agent, the identifier the tool used when making requests. [1]

Where exposure is suspected, the firm advises revoking the tokens that pushed the commits and rotating repository, organization and environment secrets available to the affected repositories. Deleting the branch or workflow run does not undo an exposure that has already happened. [1]

For longer-term protection, Wiz recommends requiring reviewers for environments holding production secrets and restricting cloud trust to protected branches or environments. It also recommends replacing personal access tokens, password-like keys tied to individual users, with GitHub Apps, separately installed integrations with their own limited permissions, or short-lived, narrowly permissioned tokens. It recommends isolating self-hosted runners too. [1]

About two-thirds of the implicated accounts were no longer available on GitHub by October 24. Wiz said that likely reflected response activity after it notified GitHub, though it did not establish the reason for each disappearance. [1]

Topics: Cybersecurity

Every edition in brief, three times a day, on our Telegram channel, on Bluesky and on Threads.

Sources
  1. Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbles | Wiz Blog Hacker News
  2. GitHub Actions holds potentially malicious workflows for approval - GitHub Changelog github.blog