Git history exposes secrets long after deletion on GitHub

At a glance

What this is: This is an analysis of why deleting a Git commit does not fully remove exposed secrets, and how GitHub history, forks, and logs can keep the data reachable.

Why it matters: IAM and NHI teams need to treat any secret that enters Git history as compromised, because lifecycle controls after exposure matter more than cleanup after the fact.

Context

Git history is a retention system as much as a change system. In practice, that means a secret committed once can remain recoverable through prior snapshots, remote clones, forks, or archived activity even after a cleanup commit is pushed.

For identity governance, the problem is not simply removing a file from the latest branch tip. Once an API key, token, or credential enters Git history, the question becomes whether the associated non-human identity has already been exposed and should be treated as compromised.

GitHub-specific retention and public event logs widen the exposure window further, because deleted content may still be reachable through hash-based retrieval or preserved activity records. That makes exposure management, not deletion, the real control boundary.

Key questions

Q: What should teams do first when a secret has already been committed to Git history?

A: Revoke or rotate the secret immediately and treat the credential as compromised, even if the bad commit has been removed from the latest branch. Repository cleanup is only containment. The owning identity still needs to be disabled or reissued before any history rewrite can be considered complete.

Q: Why does deleting a commit not fully remove an exposed secret?

A: Because Git preserves earlier snapshots, and the secret can still exist in parent commits, dangling objects, forks, or archived event data. The visible branch tip changes, but the underlying credential may remain recoverable until every copy path has been addressed and the secret itself has been replaced.

Q: What signs suggest a Git secret leak may still be active after cleanup?

A: A lingering commit hash in a fork, a clone made before the force push, or preserved push metadata can indicate the exposure still exists outside the origin repository. If the credential has not been rotated, the leak should be assumed active even when the latest history looks clean.

Q: How should organisations govern secret exposure across Git, forks, and archives?

A: Use an NHI lifecycle approach that ties secret ownership to revocation, rotation, and offboarding of the underlying credential. The control boundary is the exposed secret and every copy of it, not the repository where it first appeared.

Technical breakdown

How Git commit history preserves deleted secrets

Git stores every commit as part of a directed graph. A later commit can remove a file from the current branch tip, but the earlier snapshot still exists in parent commits and can be checked out if someone knows where to look. That is why deleting a file, or even committing a removal, does not rewrite the past. The real issue is that Git treats history as durable state, not a temporary cache. Practical implication: treat any secret committed to Git as exposed material, not as something that can be safely “deleted” in place.

Practical implication: Revoke the secret as soon as it appears in history, because removal from the latest commit does not remove the earlier snapshot.

What force-pushes and dangling commits actually change

A hard reset plus force push rewrites the remote branch pointer, but it does not instantly erase the underlying object. The old commit can become dangling, meaning it is unreachable from normal branch history yet still present in the object database until garbage collection runs. On shared platforms, that delay matters because local clones and mirrored copies may still retain the data. Practical implication: understand that history rewriting changes visibility, not immediate existence, and assume the old object may still be accessible for some time.

Practical implication: Use history rewriting as containment, not as proof of deletion, and pair it with immediate credential replacement.

Why forks and event logs outlive repository cleanup

Even if the origin repository is cleaned up, forks created earlier can preserve the sensitive commit independently, and public event logs can preserve the commit hash. That creates two separate persistence paths: one in copied repository history and one in metadata about the push itself. Someone who obtains the hash can sometimes retrieve the commit before garbage collection removes it. Practical implication: secret exposure on GitHub is a distribution problem, not only a repository problem.

Practical implication: Scan forks, archive sources, and event logs when investigating secret exposure, because the original repo is only one persistence point.

Threat narrative

Attacker objective: The objective is to recover a valid credential or token that still works outside the repository, even after the original commit is deleted.

1. Entry occurs when a sensitive file or credential is committed to Git and pushed to a remote repository, making the secret part of durable history.
2. Credential access follows when an attacker or third party retrieves the commit through repository history, a fork, or a preserved event hash.
3. Impact is the exposure and potential reuse of the underlying non-human credential, which can lead to further access or abuse elsewhere.

Breaches seen in the wild

• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Git history creates exposure persistence, not just version control. Once a secret is committed and pushed, the governance problem changes from file removal to credential lifecycle control. Branch cleanup, force-pushes, and commit rewriting may hide the secret from normal views, but they do not guarantee that every copy, fork, or log has disappeared. The practitioner conclusion is simple: history is not a safe hiding place for secrets.

Secret exposure in Git is an NHI problem before it is a source-control problem. The asset at risk is the credential, token, or key that authenticates a non-human identity, not the commit itself. That means the correct response sequence is exposure detection, identity correlation, revocation, and replacement. Teams that wait for repository cleanup before treating the secret as compromised are already operating too late.

Persistent commit metadata creates an identity blast radius that most remediation playbooks underestimate. Even when content is removed, hashes, forks, and archived push events can preserve enough evidence to reconstruct exposure. Identity blast radius: the set of downstream systems, clones, and copies that can still act on a leaked secret after the source repository is cleaned. The practitioner implication is that exposure handling must extend beyond the origin repo to every copy path the secret may have taken.

Deleting a commit is a containment step, not a control outcome. GitHub and Git do not share the same deletion semantics that practitioners often assume from application data systems. In identity terms, the secret remains governed by every place it was ever materialized, which means ownership, revocation, and rotation must be anchored to exposure, not to the repository state. The practitioner conclusion is that governance ends only when the credential is dead everywhere.

Git secret leakage is a lifecycle failure, not an isolated coding mistake. The article points to a broader control gap: organisations often manage code history carefully but fail to govern credential lifecycle across commit, clone, fork, and archive paths. The implication is that secret handling needs the same ownership and offboarding discipline that NHI programmes apply to any other credential estate. Practitioners should treat Git as one distribution channel among many, not the boundary of control.

From our research library:

• 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 next: MFA Guide

What this signals

Identity blast radius: once a secret lands in Git history, the affected credential can spread across forks, clones, and logs in ways that outlive the source repository. That changes remediation from a code hygiene task into a credential governance task, with revocation and ownership tracing at the center.

Access review processes assume the object under review still exists in a stable state. A leaked token may already have been copied into places the original team no longer controls, so the practical control is not inspection after the fact but exposure-driven replacement before reuse.

Git history is a distribution layer for secrets, which means teams need to watch the full copy path, not just the latest commit. The governance gap is the assumption that repository cleanup equals secret cleanup.

For practitioners

• Treat any committed secret as compromised Revoke or rotate the credential immediately after discovery, even if the offending commit has been removed from the branch tip. Do not wait for repository cleanup to finish before disabling the associated non-human identity.
• Rewrite history only after revocation Use history-rewriting tools to remove the object from reachable Git history, then force-push the cleaned branch and tags. Treat this as exposure containment, not as proof that no other copy exists.
• Check forks and cloned copies Ask collaborators to re-clone the repository and investigate forks, mirrors, and any CI or GitHub workflow logs that may still contain the hash or secret material. Exposure often persists outside the origin repository.
• Correlate the secret to its owning NHI Map the exposed token or key back to the service account, API key, or workload identity it authenticates so the right owner can disable access and validate downstream impact.

Key takeaways

• Git history can keep secrets reachable after deletion, so removing a file or rewriting a branch does not restore credential safety.
• The exposure risk extends beyond the origin repository into forks, clones, and event logs, which makes the identity blast radius larger than most teams expect.
• The limiting control is immediate secret revocation and rotation, not confidence in repository cleanup.

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.
• Commit History Review: Commit history review is the practice of inspecting earlier repository revisions, not just the current code state, for exposed secrets. Deleting a credential from the latest version does not erase it from prior commits, so historical scanning is essential for preventing attackers from recovering old secrets.
• Secrets Rotation: Secrets rotation is the practice of replacing credentials on a schedule or after an event so exposed values stop working quickly. In NHI programmes, rotation must be tied to ownership and automation, otherwise credentials remain valid long after teams believe the risk has been addressed.

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 building or maturing an IAM programme, it is worth exploring.