News · Threat Intelligence

GhostAction returns: about 1,900 GitHub accounts used to target more than 30,000 repositories

A renewed GhostAction wave pushed malicious GitHub Actions workflows to more than 30,000 repositories and tried to extract 3,174 secrets. Old, unrotated credentials did much of the work.

A build pipeline is trusted to hold the keys to almost everything: cloud accounts, package registries, AI services. When an attacker can quietly add one file to that pipeline, those keys can leave the business on the next run.

That is what the GhostAction campaign does, and it has returned at scale. Security firm GitGuardian reports that between 8 and 12 October 2026 the attackers targeted more than 30,000 repositories across 3,000 users and organisations, using the compromised GitHub accounts of about 1,900 users, and attempted to extract 3,174 secrets from public repositories' build systems.

Reporting cut-off: 16 October 2026. This article draws on GitGuardian's research update of 13 October 2026 and the supplied report from The Hacker News. The accompanying image is original conceptual artwork, not a photograph of GitHub systems or evidence from the incident.

What happened

GhostAction was first discovered in September 2025. The attackers take over genuine developer accounts, using stolen personal access tokens or credentials harvested by information-stealing malware, and use that access to push a malicious automation workflow into the developer's repositories.

The workflow files carry reassuring names such as "Security Audit" (security-audit.yml) or "GitHub Actions Security" (github_actions_security.yml). When they run, they collect build secrets, cloud credentials, package registry tokens for services such as npm, PyPI and Docker Hub, and AI provider keys, then send them to the attackers.

A new wave began on 31 August 2026. GitGuardian describes it as more experimental and manual than earlier waves, with the payload changing over time:

• The first new version added scanning of a repository's git history for secrets, not only its current files.
• A second version captured the lines around each AWS key ID it found, so the key could be paired with its matching secret.
• A third version extended that context capture to the full history scan.

The latest payload was deployed in phases: first to 160 previously observed victims, then, 20 minutes later, to 28,000 new repositories between 8 and 9 October. Further waves followed on 10 and 12 October, but GitHub began preventing the malicious workflow from running from 9 October, so GitGuardian says those later waves could not extract any secrets.

Why old credentials matter

Some of the victims in this burst had already been hit in the September 2025 and August 2026 waves. GitGuardian's conclusion is that the attackers are relying, in part, on secrets that were stolen months or years ago and never rotated.

That has a practical consequence. Rotating the secrets the malicious workflow stole is not enough. The GitHub credential that allowed the workflow to be added in the first place must also be found and revoked, or the same door stays open for the next wave.

What this means for your organisation

This is not a breach of GitHub itself. It is a reminder that the systems which build and ship software are often the most connected, most privileged part of an estate, and that a single reused token can turn them against you.

Sensible steps for any team using GitHub Actions:

• Review recent commits for workflow files you did not create, particularly anything named as a security or audit job.
• Revoke and reissue personal access tokens, and prefer short-lived, narrowly scoped credentials.
• Rotate every secret exposed to build pipelines, including cloud keys, registry tokens and AI provider keys.
• Scan git history, not only current files, for secrets committed in the past.
• Treat developer machines as part of the attack surface, because infostealer logs are where many of these tokens come from.

Where Firevault fits

GhostAction is a credential theft campaign, and the first response is identity hygiene: revoke, rotate and monitor. Physical disconnection does not stop a stolen token being used against a connected service.

What it can do is protect the recovery assets an organisation would need if stolen keys were used to delete or encrypt cloud data and repositories. Offline Secure Storage® keeps those copies on dedicated hardware that has no network path between sessions, so a credential that reaches the connected estate cannot reach them. Where the concern is automated systems acting on stolen access, Control by Firevault adds local physical enforcement points that can cut the path itself.