GitHub deleted commits still leak secrets at scale

At a glance

What this is: This is a secrets-exposure analysis showing that force-pushed, deleted GitHub commits remain recoverable and can still contain active credentials at scale.

Why it matters: It matters because IAM and NHI teams cannot rely on source control history rewriting to remove credential risk, especially where leaked PATs, cloud keys, or config files can still drive downstream access.

By the numbers:

• I scanned all zero-commit force push events since 2020 and uncovered secrets worth $25k in bug bounties.

👉 Read TruffleHog's analysis of deleted GitHub commits and leaked secrets

Context

Deleted commits are not the same as revoked credentials. In GitHub, a force push can make a commit unreachable from normal branch history while the underlying content still remains recoverable through event data, archive data, or direct commit references. For identity teams, that means the secret exposure problem does not end when a repository history looks clean.

The governance gap is straightforward: organisations often treat commit deletion as remediation even though the credential itself may still be valid. That creates an NHI lifecycle failure, not just a source code hygiene problem, because leaked tokens, PATs, and config secrets can continue to represent standing access until they are rotated or revoked.

Key questions

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. A deleted commit can still be recovered through archive data, hashes, forks, or direct commit references, and the credential inside it can remain valid. Security teams should treat deletion as evidence of exposure, then revoke or rotate the secret before considering the incident closed.

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. That creates a lifecycle problem, not just a code hygiene issue, since a token, PAT, or key may remain usable until it is explicitly revoked. Identity teams need exposure response, not just repository cleanup.

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. Pairing GitHub event data with archive sources makes hidden commit discovery scalable, which is useful when secrets may have been buried long before detection.

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.

Technical breakdown

Why deleted Git commits still expose secrets

A Git commit is a content object, not just a branch pointer. When a developer force-pushes after resetting history, the branch reference changes, but the commit and its blobs can remain accessible through archival systems, reflogs, commit hashes, forks, or API paths. That is why deleted history can still contain secrets even when local tools show a clean branch. The important identity lesson is that revocation must target the credential, not the repository record. A leaked PAT, cloud key, or token in a deleted commit remains a live NHI until it is invalidated.Practical implication: Treat commit deletion as an exposure event, not a containment step.

Practical implication: Treat commit deletion as an exposure event, not a containment step.

Zero-commit push events and archive-scale secret discovery

A zero-commit PushEvent is a useful signal because it often indicates a force push that rewrote branch history without adding new commits. By pairing GitHub Event API records with GH Archive, researchers can identify those events at scale and then inspect the referenced pre-force-push commit. This changes the economics of secret hunting: what once looked like a one-repo mistake becomes a searchable, large-scale exposure surface across public history. In NHI terms, the problem is not merely accidental leakage. It is persistent credential discoverability after the developer believes the evidence is gone.Practical implication: Monitor history-rewrite events as part of secret-exposure detection, not just code scanning.

Practical implication: Monitor history-rewrite events as part of secret-exposure detection, not just code scanning.

Why leaked GitHub PATs create supply-chain blast radius

A personal access token in a deleted commit can be far more dangerous than a simple secret string because its privileges may extend across repositories, CI pipelines, and release workflows. In the case study, the token had admin access to an entire open-source project family, which meant one leaked credential could have enabled code changes, pipeline tampering, or release manipulation. That is the core NHI failure mode: credential scope persists independently of where the secret was found. Once a token is valid, the blast radius is defined by its entitlements, not by the location of the leak.Practical implication: Map every leaked token to its entitlement scope before you assess impact.

Threat narrative

Attacker objective: The attacker objective is to recover a valid credential from deleted Git history and use it to obtain broader repository, pipeline, or release control.

1. Entry occurred when a secret was committed into a repository and later hidden by a force push, but the credential remained recoverable from archived history and commit references.
2. Escalation happened when the leaked PAT or other secret was valid and carried broad repository or platform privileges, turning a single mistake into reusable access.
3. Impact followed when that access could have been used to read environment data, alter pipelines, push code, create releases, or compromise the supply chain.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

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 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.

Git history is now part of the NHI attack surface: GitHub event streams, archive data, and dangling commits create a searchable recovery path for secrets that developers thought were gone. That expands secret exposure beyond the repository itself into the surrounding telemetry and archival ecosystem. Practitioners need to treat deleted commits as durable NHI exposure artefacts, not transient mistakes.

Blast radius is determined by entitlement scope, not leak location: A single PAT can create infrastructure-wide risk when it inherits admin permissions across repositories, pipelines, or release workflows. The secret may be found in a README, a .env file, or an orphaned commit, but the damage comes from what that credential can do once discovered. This is why secret inventory alone is insufficient without entitlement mapping.

Secret rotation must start at discovery, not at confirmation: The post makes clear that once a secret has been committed, discovery is already a security event. Waiting to determine whether the commit is still reachable delays the only control that matters, which is revocation of the credential itself. The practitioner takeaway is immediate lifecycle treatment for every exposed secret, regardless of how long the history looks erased.

Hidden commit exposure creates a durable trust debt: Each deleted commit that still contains a credential adds unresolved risk to the organisation's identity estate. That debt accumulates across developers, repositories, forks, and public archives, making ad hoc cleanup increasingly inadequate. Teams need a policy stance that assumes public exposure persists unless the credential is verifiably invalidated.

From our research:

• 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.
• Forward-looking: The 2024 survey found that only 44% of organisations are currently using a dedicated secrets management system, according to The 2024 State of Secrets Management Survey.

What this signals

Deleted-commit exposure is a lifecycle problem, not a repository problem: When force-pushed history can still be reconstructed, the control boundary shifts from source control hygiene to credential governance. That is why secret scanning, revocation, and access scope mapping need to operate as one workflow rather than separate teams and ticket queues. Practitioners should expect more history-rewrite detection to be folded into NHI operations.

Secret sprawl creates durable trust debt: 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025. That scale means hidden commits are not an edge case, they are part of the normal exposure landscape, so organisations need continuous discovery and rapid invalidation processes.

The more organisations depend on developer workflows, the more they need a defined response path for leaked credentials that survive history rewrites. The practical shift is simple: if a secret has ever been committed, assume it belongs in the same response queue as any other exposed NHI and close the access path first.

For practitioners

• Treat deleted commits as exposure events Trigger secret response workflows whenever a force push or history rewrite occurs. Validate whether the old commit, its blobs, or any archived copy may still contain credentials, then move immediately to revocation rather than assuming the repository cleanup was enough.
• 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. Impact assessment should start with what the credential can access, not where it was found.
• 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. Use the event stream as a signal for possible secret recovery, especially in public-facing repositories.
• Revoke before you investigate fully When a credential appears in deleted Git history, assume it is recoverable until proven otherwise and revoke or rotate it first. Investigation can continue after containment, but the access path must be closed immediately to limit supply-chain exposure.

Key takeaways

• A deleted Git commit can still expose live credentials, so history rewriting is not a valid control for secret removal.
• The article's own scan of zero-commit force pushes found $25,000 in bounty-worthy secrets, showing this is a searchable scale problem.
• The right response is revocation, entitlement mapping, and history-rewrite monitoring, not confidence in branch cleanup.

Key terms

• Dangling Commit: A dangling commit is a Git commit that is no longer referenced by an active branch or tag. The object may still exist in storage or archives, which means any secrets inside it can remain recoverable even after developers think the change has been removed.
• Zero-Commit PushEvent: A zero-commit PushEvent is a GitHub event where a push records no new commits, often because history was rewritten with a force push. In secret governance, it is a useful signal that a previously visible commit may still be recoverable and worth scanning for exposed credentials.
• Credential Revocation: Credential revocation is the act of invalidating a token, key, certificate, or other secret so it can no longer authenticate. In NHI governance, revocation is the actual containment control after exposure, because deleting the file or commit does not remove the access path itself.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, collaboration tools, repositories, and pipelines. It creates many more places for non-human identities to be exposed, which makes discovery, ownership, and timely revocation harder than in a centralised secrets model.

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.

👉 TruffleHog's full post covers the zero-commit scan method, archive workflow, and Istio case study

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.