GhostAction Returns: A “Security Audit” Workflow That Sweeps Your Whole Git History

The workflow is named like a security tool and does the opposite. It reads every secret your repository has, and it also reads every secret your repository ever had. Researchers at StepSecurity and Socket report that on 8 October two compromised maintainer accounts were used to commit the same malicious workflow into about 345 repositories within minutes. It is the latest wave of a campaign called GhostAction, which GitGuardian first documented in 2025 and reported again for August and September 2026.

The new twist is the history sweep. Removing a secret from the current files does not remove it from the git history the workflow can search.

What the researchers report

StepSecurity and Socket give matching accounts of the 8 October burst. One account, that of Takashi Kitao, was used to push the workflow into 27 repositories, including the pyxel game engine, within minutes (the two reports differ on the exact window). The other, belonging to Henry Wu, pushed it into 318 repositories, 39 of them sources and 279 forks, in about 16 minutes, among them the uber/athenadriver repository. Both researchers describe the accounts as the victims' own identities used by someone else, not attacker-owned accounts.

The file. Names reported include security-audit.yml, github_actions_security.yml and security-check.yml. It runs on manual trigger and on any push, to any branch or tag.
What it takes. The names of the repository's Actions secrets, taken from its legitimate workflows, plus a search of the working tree and the full git history, including all branches and tags, for 13 credential patterns. It also pairs AWS access key IDs with the secret keys found nearby.
What it looks for. AWS keys and session tokens, Anthropic, OpenAI and OpenRouter keys, GitHub and GitLab tokens, Google and Firebase keys, Slack tokens and SendGrid keys, plus the named Actions secrets, which can include package-publishing credentials.
Where it goes. Everything is collected into one variable and sent in a single HTTP request to a hard-coded address. Socket notes the request carries a repository identifier even when no credentials are found, which would let the operator map repositories where the workflow runs.
The pyxel case. Socket calls it the clearest confirmed case of publishing credentials being targeted: the payload names a PyPI login, a crates.io token and a GitHub token. The project is distributed through PyPI and crates.io, so stolen publishing tokens would be a route to a poisoned release. Both researchers say no malicious package versions had been published at the time of writing.

Beyond that burst, Socket says it has identified more than 500 GitHub accounts that committed the malicious workflow to tens of thousands of repositories since 7 October. That is Socket's own figure, its write-up does not describe how it was measured, and the vendors' counts differ and keep changing, so treat it as an order of magnitude. GitGuardian reported 772 public repositories hit between 31 August and 30 September, with 2,577 secrets targeted, and said only 16% of those repositories had been effectively cleaned by 5 October.

What is not established

How the accounts were compromised. StepSecurity and The Hacker News call a personal access token from infostealer logs or credential dumps “most plausible.” That is the researchers' speculation, not a finding.
Whether stolen credentials were used. Nobody has published evidence either way.
Whether the workflow ran everywhere it was planted. Socket observed it running in some repositories, not all. A planted file that never ran has not yet taken anything.
The real scale. The 345-repository burst is well documented. The tens-of-thousands figure rests on one vendor.
Who is behind it. There is no attribution, and several actors may share stolen credentials.

Why the history sweep changes the advice

The usual cleanup after a leaked secret is to delete it from the file and commit. Against this workflow that achieves nothing, because it reads history. Any key that was ever committed to any branch counts as exposed, and the same holds for forks, which carry the history with them: 279 of the 318 repositories hit through one account were forks.

It also shows how little protection a repository secret gives when write access is compromised. Anyone who can add a workflow can read the secrets that workflow is allowed to see. We made a similar point after the Truffle Security study of credentials in public repositories: deleting the commit is not the fix, revocation is.

What to do

Look for the file. Search every repository you own or maintain, on all branches, for workflows with the names above or other generic “security” names you did not write, and review workflow runs since 31 August. Check your forks and the forks of your repositories too.
Triage what it targeted. Socket suggests looking at the list of secret names inside the injected file. If it names Actions secrets, treat those as exposed; if it is empty, the history sweep is the main risk. If you cannot tell, assume both, and treat any completed run as possible exfiltration.
Revoke the credential that did the push. Revoke the token itself rather than just rotating it, then revoke sessions, OAuth grants and SSH keys on the account and re-enrol phishing-resistant multi-factor authentication.
Rotate every Actions secret and every credential ever committed. Start with publishing tokens, cloud keys and anything that reaches production. For AWS keys, check CloudTrail for use you do not recognise.
Hold releases until the repository is clean. Review the package registries' release history against your own build outputs, and do not cut a release while publishing tokens may be in someone else's hands.
Remove the workflow everywhere and revert the commit. That includes every branch, every fork you control, and organisation-owned repositories where the compromised account had write access.
Reduce the blast radius next time. Require review for changes to workflow files, require approval for workflow runs from outside collaborators, restrict outbound traffic from runners to an allow-list, and use short-lived federated credentials in place of long-lived keys where your provider supports it.

The step after rotation

A rotation produces a new publishing token or cloud key that has to reach the person who installs it. That is a human handover, and it usually happens in a chat thread or a pull request comment, which is exactly where a repository takeover gives an attacker a second chance to read it. Keep the new value out of the repository, the issue tracker and the incident channel.

Where Secretus fits, and where it does not

Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret, such as a registry publishing token.

It is not a secret scanner or a CI security tool. It does not find injected workflows, search git history, revoke tokens or protect a pipeline. Use GitHub, your scanner and your providers' tooling for that, and use a one-time link for the moment one person gives another a replacement credential.