GhostAction campaign now digs full git histories for secrets deleted years ago

The campaign is back, and it reads more than before

GhostAction, a credential theft campaign that targets GitHub Actions, first surfaced in September 2025. According to a dev.to write-up published on October 14, it resumed activity on October 7 with a wider reach and a more invasive workflow.

On October 8, attackers took over two prominent maintainer accounts and modified 345 repositories across two short bursts, according to StepSecurity figures cited in the post. Socket has since counted more than 500 affected accounts and tens of thousands of repositories.

How the attack works

The dev.to post breaks the method into three steps. The attacker first gains access to a developer's GitHub account, with a stolen token cited as one possible route. They then push a single file, .github/workflows/security-audit.yml, using a commit message that reads "Add security audit workflow". Despite its name, the workflow performs no audit: it harvests secrets and ships them to the attacker's server.

What changed in 2026 sits inside the workflow. It now sets fetch-depth: 0 to download a repository's complete history, then runs git log -p --all, which prints every change in every commit on every branch, and searches that output for keys. Earlier malicious workflows generally saw only the most recent commit, because the standard checkout action downloads just that one by default.

Deleting a secret does not remove it

Git retains every version of every file; removing a line merely adds a commit noting its disappearance, while the older commit lives on. Anyone holding the full history can recover values that vanished from the working tree long ago.

To gauge exposure, the author ran the open source scanner gitleaks across 19 repositories, producing 24 findings after deduplication. Manual triage judged 18 to be examples, tests or non-secret identifiers, leaving 6 potentially sensitive values. Two of those were passwords absent from current files but still present in an Ansible inventory committed in January 2025. The post stresses that this proves neither that the credentials still work nor that anyone has used them, only that removed values remain reachable.

Private repositories are exposed too, since a stolen token can read whatever falls within its permissions.

Revoke first, rewrite later

The instinctive response to a leaked secret, rewriting history, is the wrong first move, the post argues. Rewriting touches only your copy and the server; colleagues' clones and forks keep the old history, and anyone who already read the secret keeps it too. GitHub's own guidance agrees that revocation comes first.

The suggested order: revoke or rotate the secret at its provider, check the provider's logs for misuse, and clean the history only if the lingering value causes practical problems, such as repeatedly tripping a scanner.

Closing the door

StepSecurity emphasises a point teams often miss: rotating stolen secrets is not enough. The GitHub token that pushed the malicious workflow must also be revoked, or the attacker can simply push the same file again the next day. Recommended token hygiene includes expiry dates on every token, fine-grained tokens scoped to the repositories they need, and stripping the workflow permission from tokens that do not require it, since without that permission a token cannot modify .github/workflows.

Because a workflow pushed to any branch can run from that branch, protecting the default branch alone does not help. The post advises storing sensitive secrets in GitHub environments, which can be restricted to specific branches and gated behind human approval, and replacing long-lived cloud keys with OIDC using tight trust conditions. Old keys should still be revoked, as migration does not invalidate them.

For detection, the post points to git log --all --oneline -- .github/workflows/ to list every commit that touched workflows on any branch, plus gitleaks as both a pre-commit hook (gitleaks git --pre-commit --staged --redact) and a required, protected pipeline check before merging.

Why it matters

GhostAction invents nothing; it reads what git has always stored. That is precisely why it stings. Years-old credentials that teams believed deleted remain fully recoverable, and this campaign industrialises their collection across thousands of repositories. The only durable defence is to make old secrets worthless: revoke first, clean up second, and treat every credential ever committed, however briefly, as compromised.