GhostAction Hijacks About 1,900 GitHub Accounts to Steal CI Secrets From 30,000+ Repositories

A credential theft campaign that has been quietly working through GitHub for more than a year just had its biggest week yet. In an October 13 update, GitGuardian researchers Gaetan Ferry and Guillaume Valadon said the GhostAction campaign "targeted more than 30,000 repositories across 3,000 users and orgs" between October 8 and 12, with a major spike on October 8 and 9. That, they wrote, "resulted from compromising the GitHub accounts of about 1,900 users. It attempted to extract 3,174 secrets from public repositories' CI." The Hacker News first brought the new figures to wider attention on October 15.

If your team uses GitHub Actions, this is worth twenty minutes of your day. The attack does not rely on a clever exploit. It relies on stolen developer credentials and on secrets that never got rotated.

A campaign that never really stopped

GitGuardian first named GhostAction in September 2025, when it compromised 817 public repositories across 327 GitHub users and exfiltrated at least 3,325 secrets. The researchers now say the campaign never truly went away. Tracking the same workflow template through their data, they found waves in late 2025 and spring 2026, and then a new push that started around August 31, 2026.

Between August 31 and September 30, GitGuardian says, the malicious workflow was pushed to 772 public repositories belonging to 373 users and organizations, and the injected workflows targeted 2,577 secrets. The most common were SSH keys and deployment server credentials, Azure credentials, container registry logins, database credentials, and AWS access keys. In that wave GitHub held most runs for approval, and GitGuardian counted 26 secrets exfiltrated from 13 repositories. Only 124 of the affected repositories, about 16 percent, had been visibly cleaned up by October 5.

The October burst was different. GitGuardian's headline for the update is blunt: "this time the workflows ran."

How the attack works

GhostAction starts with access the attacker should never have had. Every malicious commit is made under the victim's own identity, using what GitGuardian describes as apparently stolen credentials. The Hacker News reports that this access comes from stolen personal access tokens or credentials harvested from infostealer logs and dumps.

With write access in hand, the attacker adds a workflow file to the repository. In the earlier waves it was named github_actions_security.yml with the commit message "Add Github Actions Security workflow." The October wave, first analyzed by Socket, used security-audit.yml and a workflow named "Security Audit." The names are meant to look like routine hardening. The workflow does nothing of the sort.

Because it triggers on every push, the workflow runs as soon as anyone commits. The older version simply hardcoded the names of secrets the attacker had spotted in the repository's legitimate workflows and posted their values to the attacker's server with a single curl request. The October payload goes further. According to GitGuardian, it also searches the repository's files and its full git history with 11 secret detection patterns covering AWS key IDs, GitHub and GitLab tokens, AI service secrets, and other cloud credentials. Later versions grab a few lines of context around any AWS key ID so the attacker can pair it with its secret key. Everything is sent over plain HTTP to 193.32.204[.]199, the same address used in the summer wave.

GitGuardian says the payload was rolled out in phases: first to 160 previously observed victims, then, 20 minutes later, to 28,000 new repositories on October 8 and 9. Some of the victims had already been hit in the September 2025 and August 2026 waves, which suggests the attackers are counting on old secrets that were never rotated.

What GitHub did

GitHub has not published its own statement about this wave that I could find. According to GitGuardian, GitHub "started preventing the malicious workflow from running starting October 9." Two later waves on October 10 and 12 used the same payload but "could not extract any secrets." That helps, but it does nothing for secrets that were already sent before the block, or for the stolen GitHub credentials that made the injections possible.

GitGuardian also makes a point that is easy to miss. Its write-up describes an XMRig cryptominer slipped into the popular kuafuai/DevOpsGPT project through the same compromised account that later pushed the GhostAction workflow, though GitGuardian doubts the same operator did both. Cross-referencing GhostAction victims with other activity on GitHub, it says it "found 13 victim repositories that were also used for cryptomining through GitHub Actions," activity belonging to "at least four distinct mining campaigns, with different wallets, pools, and infrastructure." Its conclusion is that stolen GitHub credentials get traded and reused, so "rotating the secrets exfiltrated by the malicious workflow is not enough. The GitHub credential that allowed the injection in the first place must be found and revoked too."

Are you affected?

In a local clone of each repository you maintain, list the workflow files, check their history, and search all branches for the exfiltration address GitGuardian and Socket documented, 193.32.204.199:

ls .github/workflows/
git log --all --oneline -- .github/workflows/
git log --all -S "193.32.204.199" --oneline
git log --all --oneline \
  --grep="Add Github Actions Security workflow"

Any hit means a rogue workflow was pushed with your account or a collaborator's. Then work through the steps below.

Audit your workflows. Look through .github/workflows/ in every repository you own or maintain, including old and forgotten ones, for files you did not add. Names like security-audit.yml, github_actions_security.yml, or security-check.yml, and commit messages such as "Add Github Actions Security workflow," are the ones GitGuardian and Socket documented. GitGuardian found 92 cases where the attacker simply edited a workflow left over from an earlier wave, so check history, not just new files. Also review your account's security log for activity you do not recognize.

Revoke the way in, then rotate CI secrets. If a malicious workflow ever ran, treat every secret it could read as stolen. Start with your GitHub credentials, since that is how the attacker got in: review and revoke personal access tokens you are not sure about, and sign out of sessions you do not recognize. Then rotate the repository and organization secrets, and any credentials that were ever committed to the repository's history. GitHub's secure use reference advises deleting and rotating any secret that may have been exposed.

Use short-lived OIDC tokens instead of stored cloud keys. GhostAction harvests long-lived secrets sitting in repository settings. With OpenID Connect, your workflows exchange short-lived tokens directly with your cloud provider, so there is no long-lived cloud key stored in GitHub for a rogue workflow to read and reuse later. GitHub's docs cover setup for AWS, Azure, Google Cloud, PyPI, and others.

Pin actions to full commit SHAs. GitHub's secure use guidance recommends pinning third-party actions to a full-length commit SHA rather than a tag, which helps mitigate the risk of someone slipping a backdoor into an action you depend on. This would not have stopped GhostAction itself, which writes its own workflow, but it closes a closely related supply chain route.

Limit GITHUB_TOKEN permissions. GitHub recommends granting the GITHUB_TOKEN only the minimum permissions it needs and setting the default to read-only for repository contents. You can set this per workflow or per job with the permissions key, as shown in GitHub's GITHUB_TOKEN guide. GitHub's guide also reminds you that anyone with write access to a repository can read all of its secrets, which is exactly why least privilege matters here.

The common thread in GitGuardian's research is that this campaign keeps feeding on leftovers: tokens nobody revoked, keys nobody rotated, and workflows nobody noticed. Cleaning those up is not glamorous, but it is the work that actually takes GhostAction's fuel away.