Leaked a Git Secret? Rotate It Before Rewriting History

Revoke or rotate an exposed credential before changing Git history. Remove it from current files, then decide whether its old versions must also be removed. GitHub’s sensitive-data removal guidance puts credential revocation or rotation first and warns that a history rewrite requires coordination with collaborators.

If a rewrite is necessary, preserve unpushed work, use a fresh clone to filter the affected history, inspect the changed refs, and force-push only after checking the result. The push updates repository refs; it cannot clean another person’s clone or fork. On GitHub, pull-request references and cached views may need separate attention.

Contain the exposure and decide what must disappear

Disable the leaked token, password, or key at the service that issued it. Replace the credential wherever an application or deployment still uses it, and review its activity and permissions as part of the incident response. Deleting the value from the latest commit cannot invalidate a copy someone may already have obtained.

Work out whether the exposure consists only of a credential that can be revoked, or also includes data that remains sensitive after rotation. If revocation resolves the access risk, a disruptive rewrite may offer little additional protection. If the repository must stop serving the old value, or the commits contain material that cannot be rendered harmless by rotation, plan a rewrite while recognizing that it cannot retrieve copies already downloaded.

Remove the value from current source and configuration as well as from history. Put the replacement credential in the team’s approved secret store or runtime configuration and check that the application uses it. Otherwise, the next ordinary commit can recreate the exposure in the cleaned repository.

Pause pushes and preserve work

Ask contributors to pause pushes while the rewrite is prepared and published. Identify the affected repository, branches, tags, file paths and known forks; include earlier paths if a file was renamed. Where practical, merge or close open pull requests before rewriting, since changed commit IDs can disrupt their diffs and comments.

Save needed unpushed changes outside the clone used for filtering. A fresh clone gives you a disposable working copy: if the filter removes too much or misses a path, you can discard it and start again without mixing the attempted rewrite with local work. Reapply preserved changes to the cleaned history only after checking that they do not contain the exposed material.

Filter the affected history

The git-filter-repo project lists Git 2.36 or later and Python 3.6 or later as prerequisites. Use a release that supports --sensitive-data-removal. Git’s filter-branch documentation recommends an alternative such as git-filter-repo because filter-branch has safety and performance pitfalls.

Choose the filter according to what should remain. If an entire tracked file must disappear from history, run git-filter-repo --sensitive-data-removal --invert-paths --path path/to/file in the fresh clone. Use the path within the repository, and add a separate --path for every earlier location of a moved or renamed file. Filtering its current path alone leaves old versions under other names.

If the file should remain and only specific text must go, create a replacement-text file outside the repository and run git-filter-repo --sensitive-data-removal --replace-text ../replacements.txt. That operation replaces matching text in non-binary files across the history it processes. Check the rules against every known form of the value: a partial match can leave sensitive text behind, while a broad one can change unrelated content. Keep the replacement file out of commits and do not put an active credential in a shell command.

Verify changed refs before the force-push

Inspect the rewritten working tree and history for the affected paths and values, including branches and tags beyond the default branch. Review .git/filter-repo/changed-refs for the refs the rewrite changed and for affected refs/pull/ entries. Record the tool’s First Changed Commit output for any hosted cleanup. If required work vanished or unexpected refs changed, discard the clone and revise the filter before publishing it.

With pushes still paused, confirm the destination remote and the refs that will be replaced, then run git push --force --mirror origin. This force-push can overwrite remote branches and tags, including work added while cleanup was underway. On GitHub, failures to update read-only refs/pull/ references are expected; investigate failures on other refs, including branch protection, and restore any protections changed for the operation.

Address clones, forks and hosted references

Tell collaborators which rewritten history is authoritative and have them make fresh clones where feasible. Anyone carrying local work forward should move clean changes onto the new history rather than merge an old branch into it: that merge could make contaminated commits reachable again. Coordinate separately with fork owners, because rewriting the parent repository does not alter a fork that retains the original commits.

For a GitHub-hosted repository, assess whether pull-request references or cached views still expose the material after the push. Contact GitHub Support with the repository, affected pull requests and First Changed Commit information when server-side cleanup is needed; its assistance with sensitive data is limited to cases where rotating the credential does not mitigate the risk. Keep the incident details available to the response team without recirculating the secret.

Resume pushes once contributors have the rewritten history and know how to carry forward clean work. Keep credentials outside committed files, ignore files that should never be tracked, and add a secret check to the contribution workflow. These measures also reduce the chance that an old copy or a new commit restores the exposed value.