GhostAction Has Stopped Settling for Your CI Secrets. It Now Reads the Whole Git History

Three research teams published findings on the same GitHub supply-chain campaign within about thirty hours of each other this week. GitGuardian, Socket and StepSecurity are all describing GhostAction, first reported in September 2025, and GitGuardian's data says plainly that it never went away: "Our data shows that GhostAction never really stopped."

What has changed is not how the attack arrives. It is what the injected code takes.

The 2025 version read the names of the secrets a repository already referenced in its GitHub Actions workflows and sent those values out. The version running now does that, and then searches the working tree and the full commit history for credentials matching a set of patterns — AWS access keys and session tokens, GitHub and GitLab tokens, Google, Firebase and GCP keys, Slack and SendGrid keys, and API keys for Anthropic, OpenAI and OpenRouter. It arrives as a file named security-audit.yml or github_actions_security.yml, committed straight to the default branch under a maintainer's own identity, which is why it bypasses review. As Socket puts it:

The workflow has no security function.

Three datasets, three different things being counted

These counts measure different things — injections inside a date window, repositories reached in one day's sweep, files still live on default branches — and should not be added together. The Hacker News, summarising Socket on October 9, reported more than 500 accounts committing the workflow to tens of thousands of repositories since October 7; that is an order of magnitude above anything in the vendor posts and the figure to treat most cautiously. Initial access, in all three accounts, is mundane: a maintainer's leaked personal access token, most likely from infostealer logs. Socket notes that dormant repositories were swept up with active ones, "consistent with automated enumeration rather than selective targeting."

Last year's remediation advice does not cover this year's attack

This is the practical consequence of the capability change, and Socket states it most precisely:

Rotating Actions secrets does nothing for a committed-credential exposure, and scanning the working tree does nothing for an Actions-secret exposure.

Two exposures, two separate jobs. A team that read the 2025 write-ups and rotated its Actions secrets has handled one of them. A key committed to a branch in 2023 and deleted a week later is still in the history, still readable by anything with a checkout, and no amount of secret-store rotation touches it.

What the workflows reached for matters too. GitGuardian's breakdown of the 2,577 named secrets is led by SSH keys and deployment-server credentials (446), Azure credentials (218), container registry credentials (142), database credentials (112) and AWS access keys (106). That is infrastructure access, not merely package-publishing rights.

Forks are the blast radius

Of the 318 repositories reached through one account, 279 were forks. A fork carries the workflow file and will run it where Actions is enabled, and a fork created later from an infected upstream inherits it. The repository counts above are therefore floors.

The highest-exposure project named is kitao/pyxel — 18,420 stars, 966 forks, distributed through both PyPI and crates.io, with publishing tokens in its Actions secrets. Socket reports no malicious package versions on either registry so far. "So far" is doing real work in that sentence: publishing credentials stay usable until somebody rotates them.

uber/athenadriver is the governance case: an organisation-owned repository reached because an individual retained write access as the project's original author. Organisations inherit the security posture of every personal account that can still push to them.

Detection worked. Cleanup did not

GitGuardian collected 3,669 workflow runs across 605 repositories. Only 499 executed, in 32 repositories — GitHub held most of the rest for approval — and 336 of those completed, exfiltrating 26 secrets from 13 repositories. The platform's approval gate did most of what it was designed to do.

Then: as of October 5, only 124 of the 772 repositories — 16 per cent — had been effectively cleaned. The problem was never visibility. It is that the people who needed to act did not act.

GitGuardian also found 13 victim repositories simultaneously used for cryptomining via Actions across at least four unrelated campaigns, and a cryptominer in the Docker image of kuafuai/DevOpsGPT, a project with roughly 6,000 stars, committed about a day and a half before this wave's first drop and reverted on October 4. It does not attribute the miner to the GhostAction operator, and draws a more useful conclusion: "A single compromised developer account can be exploited by several unrelated attackers."

If you maintain or depend on a public repository

Check for the two workflow filenames on every branch, back to August 31, 2026, and in forks. If either is present, treat the repository as compromised: revoke the GitHub credential that allowed the push rather than merely rotating it, rotate every Actions secret, and then scan the full history across all branches and tags and rotate what that turns up too. Hold registry releases until publishing tokens are replaced. The three advisories carry the indicators and the egress addresses to block.

Sources: GitGuardian — The campaign that never stopped: tracking GhostAction from 2025 to 2026 · Socket — New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials · StepSecurity — GhostAction Returns: Malicious "Security Audit" Workflows Now Mine Credentials from Entire Git Histories · The Hacker News — Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories