A GitHub token appears in a repository: rotate it before cleaning history

A token in a commit, issue, build log or public gist can be copied quickly. Deleting the visible line alone does not revoke a credential or remove earlier versions. GitHub's push protection can stop some supported secrets before publication, but coverage depends on the token type and repository settings; a successful push is not a safety verdict. The right order is containment, credential replacement, investigation and then repository cleanup.

Before you start​

Identify the token owner and the service it grants access to without pasting the secret into a chat or ticket. If someone else owns it, notify them through a secure channel. Preserve the alert and commit identifier; avoid reposting the token as evidence. Work from the vendor's official account settings for revocation.

Do it step by step​

1. Revoke or rotate the exposed token at its issuer immediately. For a GitHub personal access token, use GitHub Settings, Developer settings, Personal access tokens and delete the affected token. Replace it with a narrower, expiring credential only if the integration still needs one.
2. Check the token's accessible repositories, scopes and recent use where the provider offers that information. Inspect GitHub's security log and affected repository activity for unexpected pushes, workflow runs, releases or permission changes.
3. Update the application or CI secret store with the replacement token. Test the smallest necessary operation. Remove the old value from local configuration and build logs while keeping an audit record that does not contain the secret itself.
4. Remove the secret from the current file or commit. If it appears in Git history, follow GitHub's sensitive-data removal guidance and coordinate a history rewrite with collaborators; rewriting can disrupt clones and does not erase copies already fetched.
5. If push protection blocked the push, inspect the blocked file and remove the secret before retrying. Do not choose a bypass reason simply to get a build through. A blocked credential may already exist in your local Git history or another destination.
6. Review incident scope with your team: downstream deployments, third-party logs and any data the token could read. Record what was rotated and when, and add a safer secret-storage method to prevent the same mistake.

Check the result​

The old token no longer authenticates, the replacement has minimal access, affected workflows function, and the repository no longer exposes the value in the reachable locations you control.

If something goes wrong​

If revocation breaks production, restore service with a new credential rather than re-enabling the leaked one. If the token is not yours, the issuer or owner must revoke it; GitHub also documents credential-revocation mechanisms for exposed GitHub tokens. Treat an unknown token format as potentially live until checked with its issuer.

Know the limit​

History cleanup cannot guarantee every clone, cache or screenshot is gone. Secret scanning supports only recognized patterns and may be configured differently by repository. Rotation is the security fix; removing text is a separate hygiene and privacy step. GitHub push protection GitHub token revocation