Gheist campaign: stolen GitHub tokens used to commit 'ci: sync config' workflows on ci-sync-* branches that dump GitHub Actions secrets into logs and delete the runs. Am I affected and what do I rotate?

What it is: since mid-September 2026 an actor has been using stolen GitHub tokens (personal access tokens and similar, mostly harvested by infostealer malware) to push a short-lived workflow into every repository the token can write to. The workflow writes the repository's Actions secrets into its own log in an encoded form that slips past GitHub's log masking. The attacker downloads the log through the API and deletes the run within seconds. Wiz counted more than 13,500 planted branches across more than 850 accounts, including private enterprise repositories, and activity was still being seen on October 24. GitHub's protection that pauses suspicious workflow runs stopped the public-repository runs Wiz checked, but it does not cover private repositories or GitHub Enterprise Server. Am I affected / how to check: - Look for branches named ci-sync- followed by 6 lowercase letters or digits, commits titled 'ci: sync config', and a workflow named sync-check, including in deleted branches and in the reflog of forks and mirrors. - Organization and enterprise audit logs: API requests with the user agent 'gheist', workflow runs created and deleted within seconds, branch create/delete bursts from a single token, and workflow_run deletion events. - Check which tokens have write access to the affected repos (fine-grained PATs, classic PATs, OAuth and GitHub App tokens) and whether any belong to a developer machine that may have run an infostealer. Fix: 1. Revoke the token that pushed the branch, and any other tokens issued to that user, then rebuild or clean the developer machine it came from (assume an infostealer; reset browser sessions and other saved credentials too). 2. Rotate every Actions secret that the planted workflow could read: repository, organization and environment secrets for each touched repo. Rotate at the provider (cloud keys, npm/PyPI tokens, deploy keys, database passwords), not just in GitHub. 3. Review cloud and registry logs for use of those secrets since September 15, 2026. Harden afterwards: - Require reviewers on deployment environments and keep high-value secrets in environments rather than plain repository secrets. - Use OIDC federation to cloud providers instead of long-lived cloud keys, and prefer short-lived, fine-grained tokens with an expiry over classic PATs. - Protect branches and restrict who can create workflows; consider requiring approval for workflow changes, and alert on runs deleted shortly after creation. - Enable the organization policy to restrict or review personal access token access, and audit tokens regularly. Sources: https://www.wiz.io/blog/gheist-attempted-scaled-abuse-of-stolen-github-tokens-stumbles https://thehackernews.com/2026/10/gheist-uses-stolen-github-tokens-to.html