A confirmed leaked secret that is still valid usually comes first. An attacker needs no exploit, only the credential. A critical CVE matters only if it is reachable and exposed. Rotate the secret immediately, then work the CVE queue by exposure and exploitation evidence.
Why a live secret is different
A vulnerability needs conditions: a vulnerable version, reachable code, attacker controlled input. A valid credential skips all of that. If the secret grants access to production data, anyone who finds it has that access, and finding it can be automated.
So the question for a leaked secret is not how likely an exploit is, but whether the credential is valid, how broad its permissions are, and who could have seen it.
Ranking table
| Situation | Priority |
|---|---|
| Valid secret with broad production access, exposed publicly | Emergency |
| Valid secret, private repository only, narrow scope | High |
| Revoked or expired secret | Clean up history, low urgency |
| Critical CVE, exploited, exposed and reachable | Emergency |
| Critical CVE, unreachable or internal only | Standard, follows the vulnerability policy |
Two emergencies at once is possible. Handle the secret first if it takes minutes, since rotation is usually fast.
Steps for a leaked secret
- Confirm validity. Check whether the credential still works, without using it in ways that cause harm.
- Revoke or rotate it at the provider. Do this before cleaning the code.
- Check the logs for use of that credential since the time it was exposed. Look for access from unfamiliar places.
- Scope the damage. What could the credential reach? Rotate related credentials if needed.
- Remove it from the code and replace it with a reference to a secrets manager.
- Clean history if appropriate. Removing it from the latest commit is not enough, since earlier commits and forks may keep a copy. Treat it as compromised regardless.
- Add prevention: a pre commit or pipeline check for secrets, and short lived credentials where possible.
Deleting the file from the repository does not make the secret safe. Always rotate.
What about the CVE?
Run the CVE through the usual signals: exploitation evidence, exposure, reachability, importance of the asset. If it is on a known exploited list and the service is internet facing, it joins the emergency path. Otherwise it follows its tier. CISA describes its catalog as an input to prioritization, not a replacement for judgment.
Different owners, same urgency scale
Secrets are often handled by whoever manages the credential, while CVEs belong to service owners. Use one shared scale so the two queues can be compared, and make sure the person on call knows both exist.
Quick check
Is a leaked secret in a private repository an emergency?
Not always, but rotate it anyway. Rank by who can see the repository and how broad the credential is.
Is deleting the commit enough?
No. Assume anyone with access to the history or a fork may have copied it, and rotate the secret.
Sources
Last reviewed: 19 October 2026.
