- GitGuardian says GhostAction targeted over 30,000 GitHub repositories between October 8 and 12, with a spike on October 8 and 9, using about 1,900 compromised accounts.
- Some October victims were hit in earlier waves too. GitGuardian takes this as a sign that stolen secrets were never rotated.
- Rotating stolen secrets is not enough. Also find and revoke the GitHub credential that let the attacker in.
A stolen key can have many owners
Most firms treat a stolen login like a stolen laptop. One thief, one incident, one cleanup. GitGuardian's research on GhostAction points to a different picture.
The lesson here is that a leaked developer login can be passed around. Cleaning up after one attacker does not tell you who else holds the same key.
What GitGuardian found
GhostAction is a campaign against GitHub, where many companies store and build their software. GitGuardian first reported it in September 2025. That wave compromised 817 public repositories across 327 users.
On October 13, 2026, GitGuardian posted an update. Between October 8 and 12, the attacker went after more than 30,000 repositories. They belonged to 3,000 users and organizations.
Most of the activity came in a spike on October 8 and 9. About 28,000 new repositories were hit in that window.
The attacker got in through about 1,900 compromised GitHub accounts. The goal was to pull 3,174 secrets from the CI of public repositories. CI is the system that builds and tests code automatically.
GitGuardian says this wave looks more manual and experimental than earlier ones. The attack code kept changing.
How the attack works
The attacker starts with a valid login to a developer account. GitGuardian says such logins come from stolen access tokens or credential dumps. The attacker uses that access to add a workflow file to a repository. A workflow is a script that GitHub Actions runs on its own.
The file has a harmless name, such as "Security Check" or security-audit.yml. In the 2026 wave, it lists the secrets that the repository's real workflows already use. It then sends their values to the attacker's server in one web request.
Each commit is made under the victim's own identity, so the change looks routine. The workflow also runs on every push, so each new commit can trigger it again.
The October version added a new step. It searched the full git history for secrets, using 11 search patterns. These cover cloud keys, GitHub and GitLab tokens and AI-related secrets.
GitGuardian argues that this step is useless on public repositories. It concludes the attacker planned to reach private ones.
The old keys still worked
Some of the October victims had been hit before, in September 2025 or August 2026. GitGuardian infers that the attacker is partly relying on secrets stolen months or years ago and never changed.
The earlier wave shows how little cleanup happened. Between August 31 and September 30, 2026, the workflow reached 772 public repositories. By October 5, public history showed only 124 of them, or 16%, effectively cleaned.
In 92 commits, the attacker reused a workflow planted by an earlier wave. Nobody had removed it. The attacker only changed where it sent the data.
GitGuardian puts it bluntly: its data shows GhostAction "never really stopped".
Other attackers may hold the same login
GitGuardian also studied a cryptominer hidden in the open-source project kuafuai/DevOpsGPT. The same compromised account pushed both the miner and a GhostAction workflow. Yet the miner used a forged author email and a disguise made for that project.
GitGuardian is not convinced one operator was behind both.
It checked GhostAction victims against other abuse on GitHub. Thirteen of them had also been used for cryptomining through GitHub Actions. That mining came from at least four separate campaigns.
GitGuardian's most likely explanation is that these logins are not private to one gang. Leaked tokens, logs from password-stealing malware and lists of stolen logins are sold and reused. One hijacked account can serve several attackers with different goals.
What held, and what to ask
Socket reported that on October 8 a burst hit 346 repositories. Unlike in September, the workflow runs executed, and Socket confirmed successful exfiltration.
GitHub began blocking the malicious workflow on October 9. GitGuardian says the waves on October 10 and 12 extracted no secrets. In this case, the attack worked before the platform block arrived.
Three questions are worth putting to your security team.
First, when a secret leaks, do we also find and revoke the GitHub token or password that allowed the change? GitGuardian says rotating the stolen secrets alone is not enough.
Second, can we list every workflow file added to our repositories in the past year, and who approved it? Look for names like "Security Check" and for edits to old workflows.
Third, which of our secrets are older than the last known incident? GitGuardian's data points to unrotated secrets as the way back in.
Changing what is inside the house does not help if the old front-door key is still in circulation.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitGuardian.
