As reported by The Hacker News, an automated campaign tracked by Wiz since September 15, 2026 is abusing stolen GitHub tokens to plant malicious workflows that exfiltrate repository secrets through GitHub Actions logs. Wiz has dubbed the operation Gheist, after the gheist user agent string present in the attackers' API requests.

Cloud Security Alert: Wiz has dubbed the operation Gheist, after the gheist user agent string present in the attackers' API requests.

Why This Matters

This campaign exploits a structural blind spot in how GitHub Actions handles secrets in workflow logs—and critically, in which repository types GitHub's automated safeguards actually protect. The technique is simple, automated, and scalable: Wiz recovered over 13,500 planted branches across 850+ compromised accounts, ranging from personal projects to enterprise private repositories.

The core issue is twofold:

  • Log masking bypass: GitHub masks known secret values in Actions logs, but its own documentation states masking is not guaranteed once a value is encoded or transformed. Gheist base32-encodes secrets before printing them, defeating the masking.
  • Protection gap: GitHub's safeguard that pauses suspicious workflow runs covers public repositories but not private repositories or GitHub Enterprise Server deployments—precisely where the most sensitive secrets tend to live.

Technical Profile

Campaign name
Gheist (Wiz designation)
Attack vector
Stolen GitHub tokens with write access
Workflow file
.github/workflows/sync-check.yml
Branch pattern
ci-sync-[6 random chars]
Commit message
ci: sync config
Exfiltration method
Base32-encoded secrets printed to Actions logs; runs deleted after download
Scope observed
13,500+ branches, 850+ compromised accounts (as of Oct 24, 2026)
Post-exploitation
AWS role assumption via organization workflows; AWS Secrets Manager enumeration observed

Who Is at Risk

Any organization using GitHub Actions with secrets stored in repositories is exposed—but the risk profile is uneven:

Technical Profile
GitHub Enterprise Server (GHES) self-hosted deployments are at highest risk because GitHub's public-repo safeguard does not apply.
Private repositories on GitHub.com are similarly unprotected by the automated pause mechanism.
Organizations with broad token scopes—especially automation accounts and service tokens with write access across many repos—amplify blast radius. Wiz observed the tool cycling through multiple tokens from several users and automation accounts within minutes.
Teams storing cloud credentials (AWS keys, Azure secrets, GCP service account keys) as repository secrets face downstream cloud compromise. CloudTrail evidence shows AWS role assumption and Secrets Manager enumeration following initial access.

Deleting the planted branch or the workflow run does not undo the exposure. Once the attacker downloads the log, the secrets are out of your control.

Detection Guidance

Defenders should hunt for indicators of compromise across GitHub audit logs, Actions history, and cloud telemetry:
  • Search audit logs for branches matching ci-sync-* and commits with message ci: sync config
  • Look for the gheist user agent in GitHub API request logs
  • Review Actions runs that were created and subsequently deleted—especially on branches that no longer exist
  • Flag unsigned commits to .github/workflows/ from accounts that don't typically commit CI configuration
  • Correlate with AWS CloudTrail for unexpected role assumptions originating from GitHub Actions ARNs
  • Monitor AWS Secrets Manager API calls (ListSecrets, GetSecretValue) from unfamiliar identities

Shield53 Recommendations

Immediate Actions

  • Audit and rotate all repository secrets for any repository where a ci-sync-* branch or sync-check.yml workflow was found. Assume every secret the repository could read has been compromised.
  • Revoke the stolen token that pushed the malicious branch. Review all tokens with write access to affected repositories—including personal access tokens (PATs), GitHub Apps, and OAuth tokens.
  • Rotate cloud credentials exposed via repository secrets, especially AWS keys. Rotate keys in IAM, update Secrets Manager, and verify no unauthorized API calls occurred using a stolen credential.
  • Review GitHub audit logs for the past 6+ weeks (campaign active since at least September 15) for anomalous branch creation, workflow runs, and deletions.

Hardening Measures

  • Adopt fine-grained PATs with repository-scoped, minimum-necessary permissions. Avoid classic PATs with broad repo scope.
  • Restrict Actions secrets to specific workflows using environment secrets and required reviewers, rather than repository-level secrets accessible by any workflow.
  • Enforce branch protection rules requiring signed commits and status checks before merge—this blocks unsigned automated commits from reaching protected branches.
  • Use OpenID Connect (OIDC) for cloud authentication from GitHub Actions instead of long-lived credentials. This eliminates stored cloud secrets entirely.
  • Monitor and alert on new workflow file creation, especially .github/workflows/*.yml commits from non-maintainer accounts.
  • Audit token inventory regularly—expire unused tokens, rotate long-lived automation credentials, and prefer GitHub Apps over user-scoped PATs for CI workloads.

The Gheist campaign underscores a persistent truth about CI/CD security: the convenience of stored secrets in developer platforms creates a concentrated attack surface. Organizations that treat repository secrets as production credentials—with rotation, minimal scope, and cloud-native authentication—will weather these campaigns. Those that don't will find their AWS, Azure, and GCP environments enumerated within hours of a token theft they never detected.