GhostAction's workflow pulls a repository's full git history to search old commits for keys, a dev.to author says
GhostAction's fake workflow sets fetch-depth: 0 and runs git log -p --all, so deleted secrets are in reach, a dev.to author reports. A credential removed from the current files is still in every earlier commit, so it has to be revoked at the provider.
The Engineer · Build desk
Key figures: 2 password values absent from the current files remain in an old Ansible inventory committed in January 2025. They were among 6 potentially sensitive values to verify, out of 24 gitleaks findings across 19 of the author's repositories.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Passwords absent from current files, in old inventory | 2 password values | 7 | |
| Potentially sensitive | 6 values to verify | 7 | |
| Gitleaks scan, 19 repos | 24 findings | 6 |
What happened
- The attacker pushes one file, .github/workflows/security-audit.yml, with the commit message "Add security audit workflow", and the workflow sends the repository's secrets to the attacker's server.
- StepSecurity says attackers swept 345 repositories in two passes of a few minutes after compromising two maintainer accounts on October 8.
- StepSecurity adds that rotating the stolen secrets is not enough, because the GitHub token that pushed the workflow must be revoked too.
Why it matters
- constraint Rewriting history cannot close the exposure on its own, because colleagues' clones and forks keep the old commits.
- exposure Private repositories are in scope. A stolen token reads whatever private repositories its permissions cover, so a private history is only as safe as the token.
- cost Closing the way back in means finding the pushing token, and old personal access tokens with no end date are the ones most likely to still be valid.
- decision Every hit in a password or key field becomes a revoke-or-verify call, because nothing in the scan output says whether the value still works.
By default, the checkout action downloads only the latest commit [4]. A workflow that wants more has to ask. GhostAction asks with one line, fetch-depth: 0, and gets everything [4]. It then runs git log -p --all, which prints every change of every commit on every branch, and the script searches that output for keys [3].
Keeping every version is what git is for. Removing a line adds a commit saying the line no longer exists, and the old commit stays [5].
The scale figures come from two security firms, as relayed by the article. Socket has since counted more than 500 accounts and tens of thousands of repositories [18]. The article does not attribute the history-scanning step to a named researcher, so the description of that step is the author's own.
The author's evidence for exposure is a gitleaks run over 19 of the author's repositories. It produced 24 findings after deduplication within each repository [6]. An assistant's first triage sorted 18 as apparently examples, tests or non-secret identifiers and 6 as potentially sensitive values to verify [7]. Six of 24 is a quarter [16]. Two of the six were password values absent from the current files and still sitting in an old Ansible inventory committed in January 2025 [7].
The author states the limit. The triage proves neither that the credentials still work nor that anyone used them, and their validity and revocation were not checked [8]. For that ratio to transfer, your repositories would need committed inventories or config files with password fields, and your scanner would need to flag them the way this one did.
The author's remediation order follows from that uncertainty. The author also says GitHub's documentation makes revocation the first action [10].
1. Revoke or change the secret at the provider [11]. 2. Check the provider's logs to see whether it was used [11]. 3. Rewrite the history only when the old value keeps causing trouble, such as setting off the scanner each time it runs [11].
On the value of a rotated secret, the author wrote: "A deleted password that still works is worth everything." [12]
What to watch
- Whether StepSecurity or Socket publish their own account of the history-scanning step, which the dev.to article describes without naming who observed it.
- Whether provider logs show any of the 6 flagged values was still live, since the author's triage did not check validity.
- Whether the author or others report an attacker using a credential that existed only in old commits.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence45
- Adoption
- Insufficient
- Hype gap+15
- Incentives
- Insufficient
- Confidence50
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
GhostAction is a credential theft campaign that targets GitHub Actions; it first appeared in September 2025 and, according to the article, came back this week.
- [2]
The attacker pushes a single file, .github/workflows/security-audit.yml, with the commit message "Add security audit workflow"; the workflow audits nothing and instead reads the secrets and sends them to the attacker's server.
- [3]
The workflow downloads the full repository history, then runs git log -p --all, which prints every change of every commit on every branch; the script searches it for keys.
- [4]
By default the checkout action downloads only the latest commit; GhostAction adds one line, fetch-depth: 0, and gets the full history.
- [5]
Git keeps every version of every file; when you remove a line, you add a commit saying the line no longer exists, and the old commit stays.
- [6]
An assistant ran gitleaks on 19 of the author's repositories; the scan produced 24 findings after deduplication within each repository.
- [7]
The assistant's initial triage found 18 findings apparently related to examples, tests or non-secret identifiers and 6 potentially sensitive values to verify; among them, 2 password values were absent from the current files and remain in an old Ansible inventory committed in January 2025.
- [8]
The triage proves neither that the credentials still work nor that anyone used them; their validity and revocation have not been checked.
- [9]
Rewriting history only touches your copy and the server; colleagues' clones keep the old history, and so do forks.
- [10]
GitHub's documentation says the first action is to revoke the secret.
- [11]
The author's order: revoke or change the secret at the provider; check the provider's logs to see whether it was used; clean the history only if the value still gets in the way, for example if it trips the scanner on every run.
- [12]
"A deleted password that still works is worth everything."
- [13]
Changing the stolen secrets is not enough; the GitHub token that pushed the workflow must also be revoked, because if it stays valid the attacker pushes the same file again.
- [14]
The token is often a personal access token created long ago, with no end date.
- [15]
Private repositories are also affected: a stolen token can read private repositories within its permissions.
- [16]
6 potentially sensitive values out of 24 findings is 25 percent.
- [17]
On October 8, two well-known maintainer accounts were compromised, and the attackers swept 345 repositories in two passes of a few minutes.
- [18]
Socket has since counted more than 500 accounts and tens of thousands of repositories.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toGhostAction: a secret deleted from the repo is still in the repo
1 article · October 13, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.