Notifications
Clear all
Topic starter
10/07/2026 9:16 pm
TL;DR: Scanning GitHub Archive zero-commit force-push events uncovered secrets worth $25,000 in bug bounties, showing that deleted commits can still expose credentials long after developers believe history has been rewritten, according to TruffleHog. Deletion is not revocation, and any programme that treats a force-push as cleanup is still carrying live credential risk.
NHIMG editorial — based on content published by TruffleHog: Guest Post, How I Scanned all of GitHub's Oops Commits for Leaked Secrets
By the numbers:
- I scanned all zero-commit force push events since 2020 and uncovered secrets worth $25k in bug bounties.
Questions worth separating out
Q: What breaks when a secret is deleted from Git history but not revoked?
A: The assumption that branch history cleanup removes access breaks immediately.
Q: Why do deleted Git commits still matter for NHI governance?
A: Deleted commits still matter because they can preserve live NHI credentials even after developers believe access has been erased.
Q: How can security teams detect secret exposure in force-pushed repositories?
A: Security teams can monitor zero-commit PushEvents, force-push patterns, and history-rewrite activity, then inspect the referenced pre-rewrite commit for secrets.
Practitioner guidance
- Treat deleted commits as exposure events Trigger secret response workflows whenever a force push or history rewrite occurs.
- Inventory credentials by entitlement scope For every leaked secret, determine whether it is a PAT, deploy key, token, or other NHI and map the permissions it carries across repositories, CI pipelines, and release workflows.
- Monitor history-rewrite signals Add detection for zero-commit PushEvents, force pushes, and other branch-history rewrites so deleted-commit exposure becomes visible to security operations.
What's in the full article
TruffleHog's full post covers the operational detail this post intentionally leaves for the source:
- The exact GitHub Event API and GH Archive workflow used to find zero-commit PushEvents at scale.
- The automation logic for reconstructing deleted commits and scanning their contents for secrets.
- The case-study token analysis showing how one leaked PAT mapped to broad Istio repository administration.
- The filenames and commit patterns that most often exposed valid secrets in the research sample.
👉 Read TruffleHog's analysis of deleted GitHub commits and leaked secrets →
Deleted GitHub commits and hidden secret exposure: what teams miss?
Explore further
10/07/2026 9:38 pm
Deletion is not revocation: This research shows that a hidden commit can still carry live credential risk even after a force push rewrites branch history. The governance assumption that code history cleanup equals access removal is false. The implication is that identity and source control teams must stop treating repository state as the source of truth for credential safety.
A few things that frame the scale:
- 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent, according to The State of Secrets Sprawl 2025.
- 15% of commit authors have leaked at least one secret in their contribution history.
A question worth separating out:
Q: Who is accountable when a leaked repository secret still grants access later?
A: Accountability sits with the team that owns secret lifecycle governance, not just the developers who made the mistake. If a leaked credential remains valid after a commit is deleted, the control failure is in revocation, entitlement mapping, and response timing. The issue is an identity governance gap, not a one-off coding error.
👉 Read our full editorial: GitHub deleted commits still leak secrets at scale
