Topic starter
10/07/2026 9:16 pm
TL;DR: Truffle Security reports that 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 think history has been rewritten. Deletion is not revocation, and force-push cleanup does not remove live secret risk.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Guest Post: How I Scanned all of GitHubâs âOops Commitsâ for Leaked Secrets”.
Key questions
Q: What breaks when a leaked GitHub secret is force-pushed out of branch history?
A: The mistaken assumption is that repository history rewriting removes exposure.
Q: Why do deleted Git commits still matter for security teams?
A: Deleted commits matter because the hidden content can still contain valid credentials, and those credentials can still be used if the account or token remains active.
Q: How should security teams remove secrets from Git history after a leak is discovered?
A: The safest approach is to rewrite history, not just edit the current file.
Practitioner guidance
- Revocation before cleanup Treat any secret committed to GitHub as compromised and revoke it before or immediately after repository history is rewritten.
- Hunt zero-commit push events Monitor GitHub Archive and public push metadata for zero-commit force-pushes that may hide deleted credential-bearing commits.
- Scan deleted commit paths Verify whether commit hashes, .patch views, .diff views, and commit-specific URLs still expose sensitive content after a force-push.
Bottom line: Deleted GitHub commits can still contain live secrets, so force-push cleanup is not the same as revocation.
What's in the full article
Truffle Security's full research covers the operational detail this post intentionally leaves for the source:
- The GitHub Event API and GH Archive workflow used to reconstruct deleted commit hashes.
- The force-push scanning method for identifying zero-commit events at scale.
- The deleted-commit retrieval paths through commit URLs, patches, and diffs.
- The Istio case study showing how a leaked PAT could have enabled broad repository compromise.
👉 Read Truffle Security's analysis of deleted GitHub commits and hidden secret exposure →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
10/07/2026 9:38 pm
Deletion is not revocation: This article shows that Git history rewriting can remove a branch reference without removing the credential risk. That distinction is central to NHI governance because the security event is the secret being exposed, not the commit object disappearing. The practical conclusion is that repository history cleanup cannot be treated as a credential lifecycle control.
A few things that frame the scale:
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
A question worth separating out:
Q: What should organisations do when a live secret is discovered in a public repository?
A: Revoke or rotate the credential immediately, confirm where it was copied, and check whether the token was exposed in other artefacts such as logs, notebooks, or chat tools. Then review why detection failed so the same token family is not missed again. Public exposure is both an incident and a control failure.
👉 Read our full editorial: GitHub deleted commits still leak secrets at scale