GitGuardian has documented a major new wave of GhostAction, a GitHub Actions credential-theft campaign first seen in September 2025. The latest activity, reported October 15, involves roughly 1,900 compromised GitHub accounts and attempts against more than 30,000 repositories belonging to about 3,000 users and organizations. The 1,900 and 30,000 figures are GitGuardian’s estimates, and the latter counts repositories targeted, not confirmed compromised. Sources differ on whether 1,900 covers the whole campaign or only the latest wave.

What Happened

The campaign abuses legitimate write access, not a flaw in GitHub Actions. Attackers obtain personal access tokens (PATs) or credentials harvested from infostealer logs and dumps, then use them to commit a new workflow file to victim repositories. The workflows are disguised as routine security or scanning jobs so they blend into a repository’s existing CI configuration.

GitGuardian observed the largest push on October 8-9, 2026. A separate wave hit 772 repositories between August 31 and September 30, 2026. The original September 2025 campaign compromised 817 public repositories across 327 users and exfiltrated at least 3,325 secrets, so this is a sustained operation rather than a one-off.

Technical Details

Once the malicious workflow runs, it:

  • Collects CI/CD secrets exposed to the runner, including repository and organization secrets mapped into the job environment.
  • Scans repository contents and the full Git history for cloud credentials, PATs, package registry tokens and AI provider API keys.
  • Exfiltrates the results over plain HTTP to 193.32.204.199.

Because the workflow executes inside the victim’s own Actions environment with the repository’s secrets in scope, it needs no exploit and little tooling. Stolen registry tokens (npm, PyPI, crates.io) and cloud keys are exactly what is needed for follow-on supply-chain compromises, and a stolen PAT lets the same actor repeat the technique against every repository that token can write to.

GitHub began blocking the malicious workflow from running on October 9. According to the reporting, the two subsequent waves therefore could not extract secrets. GitGuardian confirmed some October exfiltration, but the total number of credentials stolen is unknown.

Impact

Any organization with developers whose GitHub tokens or credentials appeared in infostealer logs is exposed. The risk is concentrated in repositories where Actions secrets include publishing tokens or cloud credentials. Even though GitHub’s block reduced later-wave impact, secrets exfiltrated before October 9 remain valid until rotated, and Git-history scanning means secrets deleted from the tree but still in history are also at risk.

Mitigation

  1. Hunt for rogue workflows. Review .github/workflows/ across all repositories and organizations for commits you did not author, especially recent files named like security scans or audits. Check for commits from unfamiliar actors or from tokens rather than interactive sessions.
  2. Check network indicators. Search runner and egress logs for connections to 193.32.204.199.
  3. Rotate secrets. If a suspicious workflow ran, treat every secret available to it as compromised: Actions secrets, registry tokens, cloud keys and AI API keys. Also rotate secrets that ever lived in Git history.
  4. Revoke and re-issue PATs. Prefer fine-grained, short-lived tokens, or GitHub Apps, over classic PATs with broad repo and workflow scopes.
  5. Reduce workflow blast radius. Set the default GITHUB_TOKEN to read-only, require review for changes under .github/workflows/ via CODEOWNERS and branch protection, and scope secrets to environments with required approvals.
  6. Address the root cause. Run infostealer-exposure checks for developer accounts, enforce hardware-backed MFA, and revoke sessions for any developer whose machine may be infected.

References