Leaked a Secret in Git? Revoke First, Clean Up Later

A developer pushes a commit with a cloud access key in a config file. Ten minutes later someone notices, deletes the line, pushes again and closes the ticket. The repository looks clean. The key still works.

That is the most common mistake in handling a leaked secret: treating it as a code problem instead of an access problem. Deleting the value from the latest commit changes what people see in the repository. It does not change what the key can do. This guide walks through the response in the order that actually reduces risk, and explains why "we removed it" is not the same as "we fixed it."

The problem is bigger, and older, than it looks

GitGuardian's State of Secrets Sprawl 2026 report counted roughly 29 million secrets detected on public GitHub in 2025, a 34% increase in newly leaked secrets year over year. Two findings in the same report matter more for response than the headline number:

• Leaked secrets stay valid for years. GitGuardian retested secrets it had confirmed as valid in 2022 and found that 64% were still not revoked in 2026.
• Private repositories are not safer. In their data, 32.2% of internal repositories contained at least one hardcoded secret, against 5.6% of public ones: about six times more likely.

The report also found that around 28% of incidents originate in collaboration and productivity tools, not in code at all. A token pasted in a chat or a ticket needs the same response as one committed to git.

The lesson is uncomfortable: detection is mostly solved; remediation is not. As the report puts it, rotation and revocation are not yet routine, owned or automated in most organizations.

Step 1: revoke or rotate before anything else

GitHub's own documentation is explicit. If the sensitive data is a secret, the first step is to revoke and/or rotate it. Once the credential is revoked, it can no longer be used for access, and GitHub notes that this may be enough on its own.

The OWASP Secrets Management Cheat Sheet says the same thing in its incident response section: exposed keys "should undergo immediate revocation," and a new secret must be created and deployed quickly, preferably through an automated process.

Why not clean the history first? Because history is not where the risk lives. Even after you rewrite and force-push, GitHub warns that the old commits can remain reachable in clones, in forks, and directly by their SHA-1 hash in cached views. You cannot remove data from other people's copies. Revocation is the only step that works no matter who already copied the value.

Revoke fast, but not blindly

GitGuardian's response guide adds a useful nuance: before you revoke, understand what the secret unlocks and what will break when it changes. A database password used by twelve services can cause an outage if you rotate it without a plan. The answer is not to wait; it is to have the plan ready before the leak:

• Know which systems consume each critical secret.
• Store the replacement somewhere safe, such as a secrets manager, not in another config file.
• Tell the teams affected that a rotation is underway.

If you cannot tell quickly what a secret gives access to, treat it as critical until you can prove otherwise.

Step 2: check whether it was used

Revocation stops future use. It says nothing about the past. OWASP lists the questions the incident response team needs to answer from logs:

1. Who had access to the secret?
2. When was it used, and from where?
3. When was it previously rotated? That defines the exposure window.

For a cloud key, that means reviewing the provider's audit logs for API calls made with it. For a database credential, look at connection logs and any unusual exports. GitGuardian recommends continuing the remediation even if you find no misuse, since an absence of evidence in the logs you have is not proof.

If you do find activity you cannot explain, this is no longer a hygiene task. It is an incident, and it should follow your incident response plan: containment, scoping and, where needed, notification.

Step 3: clean up the history and the copies

Only after the secret is dead does history cleanup make sense. It still has value: even an invalid credential reveals which systems, accounts and data stores you use. GitHub's guidance covers the details:

• Rewrite history with a dedicated tool and coordinate the force-push with everyone who works on the repository.
• Ask collaborators to delete or re-clone their local copies.
• Contact the owners of forks, because the commit stays reachable there.
• Remove the secret from any other place it was copied: logs, tickets, chat threads and build artifacts. OWASP calls out logs specifically.

Step 4: fix the cause, not just the instance

A secret leaked once will leak again if nothing changes. The prevention side has three layers:

• Catch it before it lands. Pre-commit hooks and IDE checks stop most leaks before they reach a remote. Scanning on every push and across full history catches the rest. Our guide on SAST, SCA, secrets and IaC scanning explains where each check fits.
• Make secrets short-lived. OWASP recommends dynamic secrets with short lease durations where possible, and automated rotation everywhere else, so a stolen credential only works for a short time.
• Watch outside your code. Secrets also leak through chat tools, paste sites and infostealer logs. That exposure shows up in leaked credential monitoring, not in your repository scanner.

How to prioritize when you have hundreds

Most teams that turn on full-history scanning find a backlog, not a single leak. Not every finding is equally urgent:

• Live beats dead. A secret that still authenticates is an open door. One that was already revoked is cleanup work. Validating whether a secret is still active is the single best triage signal, although GitGuardian notes that about 46% of critical secrets have no vendor-provided way to validate them.
• Privilege matters. An admin cloud key or a production database password outranks a test API token.
• Exposure matters. A secret in a public repository or a shared chat is reachable by more people than one in a private repository with three contributors, although private does not mean safe.

FAQ

Is deleting the commit enough if the repository is private? No. Everyone with access, every clone and every CI system that cached the code still has the value. Revoke it.

Should we rotate even if the logs show no use? Yes. Logs can be incomplete, and the credential stays exposed in copies you do not control.

How fast is fast enough? OWASP gives no fixed deadline; it says revocation should be immediate. For secrets in public repositories, treat it as a same-day task.

How priorIQ.ai helps

CodeIQ scans secrets across the full git history with live-secret validation, so you can tell an urgent rotation from historical noise, and adds a pipeline gate and IDE extensions to stop new leaks before they land. OnGuardIQ watches deep and dark web sources, Telegram channels and paste sites for leaked credentials from your domains. SentinelIQ triages the alerts from the SIEM you already use, so suspicious activity tied to a leaked credential reaches your team as a confirmed incident. And PriorIQ Core puts code findings in the same risk model as endpoints and cloud, so a live secret competes for attention on real risk, not on scanner volume. Request a demo.