What to Do After Pushing an API Key to GitHub: Revoke, Clean Up, and Prevent Repeat Leaks

If you accidentally push an API key to GitHub, your first priority is not deleting the commit. It is revoking or rotating the key. Making the repository private or deleting the file immediately may feel reassuring, but a secret that reached a remote repository must be treated as potentially copied.

This guide walks through the response in the right order: disable the credential, check for misuse, repair the current code, decide whether rewriting Git history is justified, and strengthen the workflow that allowed the leak. Before attempting a force push, stop the exposed key from granting access.

Revoke or Rotate the API Key First

GitHub advises treating a committed secret as compromised and rotating it immediately. Open the official management console for the service that issued the API key and revoke the exposed credential. If the application still needs access, create a different key and move each legitimate workload to the replacement.

The order matters. An API key in a public repository can be collected quickly, but a private or internal repository is not a reason to keep it active. Permissions can be misconfigured, collaborators have local copies, and logs or connected systems may retain content. Even if the key was visible for only a few seconds, revocation—not elapsed time—is the reliable boundary.

GitHub's official guide to storing secrets safely likewise recommends immediately revoking an exposed secret, generating a replacement, and storing the new value securely.

Switch Legitimate Workloads and Check Activity

After disabling the old key, identify every legitimate place that used it. Check local environment variables, hosting platforms, CI/CD systems, scheduled jobs, servers, and shared development environments. Replace the credential, then confirm that deployments and background tasks work without the old value.

Review the usage history, audit logs, and billing information available from the API provider. Look for requests outside the normal time or region, unexpected usage spikes, unfamiliar resources, and permission changes. If you find suspicious activity, assess the related account, data, and payment impact instead of treating the incident as only a source-code problem. Escalate to the provider or your organization's security contact when appropriate.

If GitHub opened a secret scanning alert, review it after the credential has been handled. GitHub's alert resolution guidance notes that removing the string from the repository does not automatically close the alert. Record the remediation and close the alert with the accurate resolution reason.

Remove the Secret From the Current Code

Do not paste the replacement key back into source code. Store it in an environment variable, a hosting platform's secret store, GitHub Actions secrets, or an approved secrets manager. Code should reference only the variable name. If contributors need a configuration template, provide a .env.example containing placeholders rather than real values.

Adding .env to .gitignore is not enough if Git already tracks the file. As the official gitignore documentation explains, you must remove the file from the index while keeping your local copy if you want Git to stop tracking it.

git rm --cached path/to/.env

Commit the ignore rule and the sanitized code. This fixes the current branch state, but it does not erase the earlier blob or commit. A later deletion commit—and git revert—leaves the original secret in Git history.

Decide Whether Rewriting History Is Necessary

Once an API key has been revoked, finding its former value should no longer grant API access. GitHub's official guide to removing sensitive data from a repository explicitly notes that revocation or rotation may mitigate the risk well enough that a disruptive history rewrite is not warranted.

History removal deserves consideration when the exposed material cannot be revoked, the commit includes other confidential data, deletion is required by policy or agreement, or the credential provider cannot reliably invalidate the value. In an organization-owned repository, do not start force-pushing on your own. Agree on the scope and timing with repository administrators and the security team.

A rewrite changes the hashes of affected commits and their descendants. It can invalidate commit and tag signatures, disrupt open and historical pull requests, conflict with branch protection, and break systems that store commit IDs. A collaborator with an old clone can also reintroduce the contaminated history. Pause repository updates and coordinate the cleanup before changing remote references.

Clean History With git-filter-repo When Required

When history removal is justified, GitHub recommends a recent version of git-filter-repo with the --sensitive-data-removal option. Work in a fresh clone dedicated to the cleanup rather than a normal working directory that contains local-only branches or changes.

If a file existed only to hold the secret, remove that repository path from all rewritten history:

git filter-repo --sensitive-data-removal --invert-paths --path path/to/file

If the key appeared inside an otherwise legitimate source file, place the replacement expression in a file outside the repository and use --replace-text. Do not paste an active or replacement key into shell history, an issue, or a chat message.

git filter-repo --sensitive-data-removal --replace-text ../passwords.txt

Afterward, check every relevant path, previous filename, branch, and tag. Confirm that the sensitive value is gone and that required code was not removed. Only then should an administrator update the GitHub repository with a coordinated force push. Follow the current GitHub procedure for the push and for any temporary branch-protection adjustment.

Handle Clones, Forks, Pull Requests, and Cached References

Rewriting the central repository does not erase old objects from collaborators' clones, forks, pull request references, or every cached GitHub view. Tell collaborators not to merge or push from a pre-cleanup clone. Re-cloning is usually the clearest path; teams that cannot re-clone must follow the careful cleanup procedure referenced by GitHub.

If a fork still contains the affected commit, coordinate with its owner. If non-revocable sensitive data remains in pull request references or cached views, contact GitHub Support with the repository, affected pull requests, and the first changed commits reported by git-filter-repo. GitHub states that Support does not purge non-sensitive data and may not perform server-side removal when rotating a credential sufficiently mitigates the risk.

A successful force push is therefore not the end of the incident. Confirm that collaborators have moved to clean history, the old key is inactive, and no remaining reference can recontaminate the repository.

Prevent Another Leak With Secret Scanning and Push Protection

GitHub secret scanning detects supported API keys, tokens, and other credential patterns across Git history. Enable the alerts available for your repository and decide who owns the response. Detection coverage is not universal, particularly for custom or transformed secrets, so scanning should support—not replace—careful secret handling.

Push protection checks supported secrets as contributors push and can block them before they reach the repository. Review the user, repository, and organization options available to you, and establish a policy that contributors do not casually bypass warnings.

Use least-privilege permissions, expiration dates, and separate keys for separate workloads. Stage files deliberately and inspect the exact content of the next commit:

git diff --cached

Environment-based configuration, narrow tracking rules, staged-diff review, and automated detection form independent layers. Together they make it less likely that one missed line becomes another credential incident.

Summary

After pushing an API key to GitHub, revoke or rotate it at the provider first. Move legitimate workloads to the replacement, inspect usage and billing, and remove the value from the current code. Rewrite Git history only when revocation does not adequately mitigate the risk, and coordinate that rewrite with repository administrators and collaborators.

The most important immediate action is not finding the fastest way to delete a commit; it is removing the exposed key's ability to authorize requests.

An accidental push is stressful, but containing it in the right order—and adding one more preventive layer—turns the incident into a practical improvement for the next commit.