A password or API key leaked

A key pushed to a public repository can be found by automated scanners within minutes. Assume it has been seen: rotating it matters more than hiding it.

Get help Bring in an expert now if

It was a cloud provider's key with broad permissions (for example an admin access key).
Logs show the key or password was used by someone else.
It gave access to customer or personal data.

0 of 13 done

Right now

Issue a new key (or change the password), then revoke or deactivate the leaked one straight away.
Deleting the commit or message doesn't help: copies already exist in history, forks, caches and scanners. Where a service lets you deactivate a key, do that first and delete it once everything works on the new one.
Update everything that used the old secret, so services keep working with the new one.
If a password was reused anywhere, change it there too.

Contain

If it's a cloud key, check the audit log (for example AWS CloudTrail) for new users, keys, machines or permission changes, and remove anything you didn't create.
Stolen cloud keys are often used to create their own access, or to run crypto miners on your bill.
Check the service's billing for unexpected usage.

Investigate

Read the service's access logs from the moment of the leak: what the key was used for, and from which IP addresses.
Open the IOC lookup
Find out how long it was exposed, and where else it might have been copied: forks, CI logs, chat history, tickets.
Search the rest of the repository and its history for other secrets.

Recover

Decide whether to rewrite git history. Once the key is rotated, that's often unnecessary. If you do, use git filter-repo, force-push, and ask collaborators to re-clone rather than merge old branches.
Close or merge open pull requests first. Rewriting never reaches forks or other people's clones, which is why rotation comes first (GitHub).
If it was on GitHub, contact GitHub Support to purge cached views of the old commits.

Afterwards

Turn on secret scanning and push protection for your repositories, and add a pre-commit check (for example gitleaks).
Keep secrets in a secrets manager or environment variables, never in code or config files that get committed.
Prefer short-lived, narrowly scoped credentials, so a leak does less harm.

Sources and further reading

This checklist was checked against these public guides, which go into more depth. Bluebench isn't affiliated with them.

General guidance, not a substitute for your own incident response plan or professional help. Your ticks stay on this page only and aren't saved.