Committed a Secret to Git? Here's Exactly What to Do

You just committed a secret to Git — an API key, a password, a token — and maybe already pushed it. Breathe. This is recoverable, but order matters. Do these steps in sequence: revoke first, assess the exposure, purge it from history, then make sure it never happens again. Do not start by deleting the line and committing again; that does nothing to protect you.

Step 1 — Revoke the secret (do this first)

Before you touch the repository, go to the provider and revoke or rotate the credential. Disable the leaked key and issue a new one. This is the only step that actually stops an attacker, because it makes the exposed value worthless. Everything else is cleanup.

• AWS: deactivate and delete the access key in IAM, then issue a new one.
• GitHub/GitLab tokens: revoke the personal access token and create a replacement.
• Stripe and other SaaS: roll the API key in the dashboard.
• Database/passwords: change the password and update the consuming services.

If the credential was high-privilege, also review recent activity logs for signs it was already used.

Step 2 — Assess the exposure

Now understand the scope so you can communicate and prioritize. Ask: Was the repository public or private? How long was the secret exposed? Which commits and branches contain it? And critically, what could the credential access? A read-only token to a sandbox is a very different incident from an admin key to production — this is the blast radius of the leak, and it determines how urgently you escalate.

Remember that the secret may exist in more than one place. If it was also pasted into Slack, a ticket, or a wiki, revoking the Git copy is not enough — you have secret sprawl to clean up too.

Step 3 — Purge the secret from git history

Even after you delete the line in a new commit, the secret remains in your history forever. To truly remove it, rewrite history with a dedicated tool. The modern, recommended option is git filter-repo; BFG Repo-Cleaner is a fast, simpler alternative for the common case.

Using git filter-repo

# Install (one time)
pip install git-filter-repo

# Put the leaked value(s) in a file, one per line, as:
#   LEAKED_SECRET_VALUE==>REMOVED
echo 'AKIA...example==>REMOVED' > replacements.txt

# Rewrite every commit
git filter-repo --replace-text replacements.txt

Using BFG Repo-Cleaner

# Remove a specific file from all history
java -jar bfg.jar --delete-files config.env

# Or replace secret strings listed in a file
java -jar bfg.jar --replace-text replacements.txt

git reflog expire --expire=now --all && git gc --prune=now --aggressive

After rewriting, force-push the cleaned history and have every collaborator re-clone — old clones still contain the secret. On hosted platforms, also ask support to expire cached views and delete any forks or pull requests that captured the value.

Step 4 — Prevent it from happening again

Cleanup is reactive; the real win is making the next leak impossible. Two controls do most of the work:

1. Add push protection so a secret is blocked at commit or push time and never reaches the repo.
2. Run continuous secret scanning across history and your other tools to catch anything that slips past — including the copies sitting in chat and wikis.

Move credentials out of code entirely by loading them from a secrets manager at runtime, and rotate them on a schedule so any future leak has a short shelf life.

Quick recap

• Revoke first — make the leaked value worthless.
• Assess — scope the exposure and its blast radius.
• Purge — rewrite history with git filter-repo or BFG, force-push, re-clone.
• Prevent — push protection plus scanning, secrets in a manager, regular rotation.