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.
At a glance
What this is: This is a research write-up showing that deleted GitHub commits can still be retrievable and still contain live secrets.
Why it matters: It matters because IAM, PAM, and NHI programmes cannot treat history rewriting as credential remediation when exposed secrets may remain exploitable.
By the numbers:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
👉 Read Truffle Security's analysis of deleted GitHub commits and hidden secret exposure
Context
Git history rewriting is not the same as secret removal. In public repositories, a force-push can make a commit unreachable from normal branch history while the underlying credential material remains recoverable through other GitHub surfaces, which is a direct governance problem for NHI credential handling.
For identity teams, the important distinction is between deleting reference to a commit and revoking the secrets it contained. When a secret is embedded in code, config, or hidden repository history, the credential lifecycle has already escaped the developer workflow and entered identity security scope.
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. In practice, the secret may still be recoverable through archive data, commit-specific views, or other platform records, so the credential remains live until it is revoked. Cleanup changes visibility, not validity.
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. Security teams need to treat commit deletion as a code-history event, not as proof that the secret lifecycle is closed.
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. Use a history-rewriting tool to remove the secret from all relevant commits, then force-push the cleaned branch and coordinate with every collaborator. Afterward, rotate the exposed credential, inspect forks and mirrors, and check CI artifacts because copies of the old history may still exist.
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.
Technical breakdown
Why zero-commit force pushes still matter
A zero-commit force push is a branch rewrite event where the pushed commit list is empty because the branch tip moved backward. That does not mean the prior commit vanished from all accessible GitHub surfaces. The article argues that GitHub Archive and the Event API can preserve enough metadata to reconstruct deleted commit hashes at scale, which turns history rewriting into a discoverable secret-hunting signal. The technical issue is not just Git storage, but distributed visibility across archive, API, and web access paths.
Practical implication: treat force-push events as possible secret exposure indicators, not as evidence that the leaked credential is gone.
Why deleted commits can still be retrievable
Git normally hides unreachable objects from everyday navigation after a reset and force-push, but GitHub’s platform behaviour can keep deleted content accessible through commit-specific URLs, archive records, or related repository structures. The article shows that if an attacker can identify the commit hash, or even enough of it, the deleted content may still be inspectable. This is why deletion is an access-path change, not a secret-lifecycle event. The credential remains valid until the upstream account, token, or key is revoked.
Practical implication: separate repository cleanup from secret revocation in your incident workflow.
Why secret scanning needs event-driven discovery
The article’s main automation insight is that the GitHub Event API and GH Archive provide a scalable way to identify candidate deleted commits without guessing commit hashes. That matters because manual review of repositories misses history that was force-pushed away, while archive-driven discovery can reveal the before hash for scanning. In NHI terms, the discovery problem is upstream of remediation: if you do not know the secret exists, rotation never begins. The control failure is incomplete inventory, not merely slow response.
Practical implication: add archive and event-stream hunting to your secret detection workflow, especially for public GitHub activity.
Threat narrative
Attacker objective: The attacker objective is to recover live credentials from deleted Git history and use them for repository access, code changes, or broader supply-chain compromise.
- Entry occurred when a secret was committed into a public GitHub repository and exposed through normal repository history.
- Credential access followed when the leaked token or secret remained recoverable after the force-push rewrite and could still be queried through GitHub-visible paths.
- Impact emerged when the article demonstrated that one token had broad administrative reach, creating a credible supply-chain compromise path.
Breaches seen in the wild
- 17,000+ Secrets Exposed in Public GitLab Repositories: Over 17,000 secrets including API keys and tokens exposed in public GitLab Cloud repositories.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
History rewriting creates secret persistence debt: Force-push workflows assume the dangerous content has been erased, but the article demonstrates that deleted commits can remain discoverable through other GitHub surfaces. That creates a persistence window for secrets that outlives developer intent and breaks the assumption that source control cleanup equals exposure cleanup. Practitioners should treat this as a lifecycle failure, not a repository hygiene issue.
GitHub Archive becomes an identity discovery layer: By mining zero-commit events, the researcher effectively turned public platform telemetry into a secret inventory source. That is a reminder that NHI discovery now extends beyond code scanning into event streams, archives, and platform metadata. The implication is that identity inventory for secrets must include indirect discovery paths, not just repository content.
Hidden commits expose identity blast radius: The Istio example shows how a single leaked PAT can create project-wide administrative exposure across a large open-source estate. That is the classic NHI blast-radius problem: one credential can bridge from a local developer mistake to wide operational authority. Practitioners should measure how much control each secret can unlock if rediscovered after deletion.
Secret governance must assume recoverability: Once a credential reaches a public commit, the relevant governance question becomes how quickly it is revoked, not whether the commit was force-pushed away. This is the control premise that needs to change across NHI and developer tooling programmes. A secret that is technically deleted but still recoverable is still governed as live exposure until revocation closes the loop.
From our research library:
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Hidden commit exposure should be treated as a secret inventory problem, not just a Git problem: Once a credential reaches a public commit, the governance task shifts to finding every place that secret can still be recovered and revoking it before the exposure is reused. Force-push workflows can hide the branch pointer, but they do not guarantee the absence of downstream access paths.
Deleted history widens the blast-radius question for NHI programmes: A single credential in source control can outlive the developer’s cleanup action and remain exploitable through archives, mirrored data, or platform metadata. That means secret governance has to measure recoverability, not just branch state, and it has to do so before attackers do.
For practitioners
- 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.
- Classify exposed secrets by blast radius Prioritise tokens and keys with repository-wide, organisation-wide, or production automation access over low-value developer credentials.
- Add hidden-history checks to CI Extend secret scanning to archived history and force-push residue, not just active branches and current working trees.
Key takeaways
- Deleted GitHub commits can still contain live secrets, so force-push cleanup is not the same as revocation.
- The article’s example produced $25,000 in bug bounties, showing that hidden history can still carry real exposure value.
- The control that matters most is rapid revocation backed by discovery that includes archive and history-based search paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article is about secrets that remain exposed after deleted commits. |
| NHI-01 — Improper Offboarding | Deleted history still leaves credentials active until they are revoked. | |
| NHI-07 — Long-Lived Secrets | Recovered tokens remain valid long after the developer thinks the secret is gone. | |
| Recommendation — Scan for leaked NHI secrets in commit history and revoke anything exposed immediately. Treat force-pushed secrets as unrecovered offboarding failures and close the credential lifecycle. Reduce long-lived secret exposure by replacing static credentials with shorter-lived alternatives. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The incident is fundamentally about credential lifecycle and revocation. |
| Recommendation — Apply authenticator management to revoke exposed secrets and enforce rotation after disclosure. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack pattern centers on harvesting leaked credentials and using them for access. |
| Recommendation — Map secret exposure to credential-access and exfiltration detection workflows. | ||
Key terms
- Dangling Commit: A dangling commit is a Git object that still exists in the repository database but is no longer referenced by a branch or tag. It may be invisible in normal history views, yet still recoverable until garbage collection removes it or a hosting platform discards it.
- Force-Push: A force-push rewrites branch history by replacing existing commits with new ones on the remote repository. It is a legitimate Git operation, but in an attack it can hide malicious changes inside preserved commit metadata, making tampering harder to detect through ordinary pull request review or feed monitoring.
- Secret Recovery Window: The secret recovery window is the period during which an exposed credential remains discoverable or usable after it was believed to be removed. In NHI governance, this window matters because detection, repository cleanup, and credential revocation are separate controls with different timings.
- Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.
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.
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org