Gheist: stolen GitHub tokens leak secrets through Actions logs

📌 Later developments: The testmetest worm: 13 MB payloads in 42 GitHub repos (October 26, 2026)

A campaign called Gheist uses stolen GitHub access tokens to make victims’ repositories run a GitHub Actions workflow that prints secrets into the logs, from which the attacker downloads them. The technical description comes from Wiz Research’s analysis, as reported by Help Net Security; The Hacker News also covered it, as did Dark Reading, which describes an ongoing supply chain attack against thousands of developer repositories, and Infosecurity Magazine, which confirms the scale: more than 13,500 branches and repositories targeted.

What happened

According to Wiz, researchers recovered more than 13,500 branches created by the attacker in repositories belonging to over 850 compromised GitHub accounts. The campaign is named after the user agent the tool sends with its GitHub API requests. Wiz does not say how the tokens were stolen.

The critical point is private repositories. Since July 28, GitHub has held potentially malicious workflow runs in public repositories until a collaborator approves them, and there the attack is blocked. That hold does not apply to private repositories or to GitHub Enterprise Server: according to Wiz, GitHub audit logs show runs on the attacker’s branches completing and then being deleted by the Gheist user agent. The exposed secrets include environment secrets, which are often production credentials.

How the attack works

The chain described by Wiz is short and stays entirely inside GitHub:

1. the tool takes a stolen token and lists every repository that token can access;
2. in each one it creates a branch named ci-sync- followed by six random characters and adds a small workflow called sync-check;
3. pushing the branch starts the workflow automatically; the workflow has one job: write the repository’s secrets into the run log;
4. to get around GitHub’s secret masking, which only recognises a secret when it appears exactly as stored, each value is encoded in base32 and ends up in the log in full;
5. the tool downloads the log through the GitHub API and deletes the run seconds later.

There is no attacker server: the secrets leave through the GitHub API, so there is no external domain or connection to block. Deleting the run and the branch, however, does not undo the exposure.

Wiz observed two variants of the tool. Since October 19, one of them adds a second job aimed at self-hosted runners: it searches the machine for tokens and keys and uses Docker to reach the host’s files.

In enterprise organisations the tool cycled through the tokens of several users and automation accounts within minutes, and cloned private repositories before planting the workflow. Hours later, cloud credentials from the same organisation were used to enumerate AWS Secrets Manager; Wiz does not say how they were obtained. The victims’ CloudTrail logs show the organisations’ own workflows running on ci-sync- branches while assuming AWS roles: proof that Actions ran without any approval.

The same accounts are also used by other groups: on October 6, 391 accounts renamed about 1,461 repositories as cracked-software lures (166 of those accounts never appear in Gheist activity), and on October 18, 25 Gheist accounts each created a “Windows RDP Runner” repository within nine minutes.

In our reading, the relevant MITRE ATT&CK techniques are T1078 (Valid Accounts), T1213.003 (Code Repositories), T1027 (Obfuscated Files or Information) for the base32 encoding, T1567 (Exfiltration Over Web Service), T1070 (Indicator Removal) for deleting the runs, and T1555.006 (Cloud Secrets Management Stores) for the AWS Secrets Manager enumeration.

Impact for European and Italian companies

Many European companies keep code and release pipelines on GitHub, often in private repositories with environment secrets that grant access to cloud accounts, container registries and production databases. A single token belonging to a developer or an automation account is enough to expose the secrets of every repository that token can reach. For NIS2 entities, security in development and in the supply chain is one of the required measures: the use of exfiltrated production credentials should also be assessed as a potentially notifiable incident.

What to do now

1. Look for traces in GitHub audit logs: the Gheist user agent, creation of ci-sync-* branches, sync-check workflows and runs deleted right after they finish.
2. Check your cloud logs: if your workflows authenticate with OIDC, search for role assumptions whose subject contains a ci-sync- branch. According to Wiz, this proves Actions ran on an attacker branch even if you collect no GitHub logs.
3. Rotate every secret available to an affected repository: repository, organisation and environment secrets. Revoke the tokens that pushed the commits, as Wiz recommends.
4. Check self-hosted runners: container launches with access to the host file system, and credentials present on the machine from October 19 onwards.
5. Reduce the attack surface (our recommendations): restrict OIDC trust policies to specific branches or environments, protect environments with release-branch rules and required reviewers, use tokens with minimal permissions and short expiry, and consider rules that stop unauthorised users from changing workflow files.

How ARXDOME helps

ARX Sentry’s agent collects logs, events and process inventory from Linux, Windows and macOS servers, including those used as self-hosted runners: it helps spot unusual container and process launches on the machine. With ARX Trace our analysts can run collections and searches across multiple machines to verify what was touched, and ARX Shield can isolate a suspicious runner from the network while secrets are rotated.

Last updated: 27 October 2026