# What is a leaked secret, and what do you do first?

> A leaked secret is a credential that reached a place it shouldn't, like a public commit or a chat. Why you reissue it first and clean up the copies second.

URL: https://crunu.com/learn/leaked-secret
Language: en
Updated: 2026-10-30

A leaked secret is a credential that has reached a place where people or systems outside its intended audience can read it, such as a pushed commit, a CI log, a chat message, a ticket or a container image, and so must be treated as known to whoever could have read it.

## Why "delete it" is not the fix

A leak is about copies, and you rarely control them all. GitHub's own guidance on removing sensitive data is blunt: for passwords, tokens and credentials, "as a first step you need to revoke and/or rotate that secret", and once you have, rewriting history "may not be warranted" ([GitHub Docs](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository)). Even after a force push, the same page notes, the commits may remain in clones and forks, in cached views and in pull requests that reference them.

*Figure: Diagram of where a secret goes once it is in a Git repository. Git host: the repository, pull requests and forks. Commit history: old commits keep the value after the file is deleted; it stays after you delete it. CI caches and artifacts: copies of the checked-out files. Every clone: laptops and build machines that pulled it; it stays after you delete it. Everyone with read access: today and anyone added later. Deleting the copy doesn’t undo the leak, so the value has to be reissued at its provider.*

So the order is:

1. **Reissue the value at its provider.** Create a new key, deploy it, then revoke the old one. Many providers let both work for a while, which avoids downtime; see [key overlap window](https://crunu.com/learn/overlap-window).
2. **Check what the old value was used for.** Providers such as Stripe show request logs per key ([Stripe](https://docs.stripe.com/keys)). Look at the period between the leak and the revocation.
3. **Clean up the copies you can reach.** Delete the message, rewrite the branch, purge the build log. This limits embarrassment and future confusion; it doesn't make the old value safe.
4. **Close the path.** Find out how the value got there and change the habit or the tooling.

## Common mistakes

- **Rewriting history and stopping there.** The value is still valid at the provider, and someone may already have a copy.
- **Reissuing but not deploying everywhere.** If the same key is used by three services and you update two, the third breaks when you revoke the old key, and people are tempted to un-revoke it.
- **Assuming private means safe.** A private repository, a private channel and an internal wiki all have more readers than the people you'd name.
- **Waiting for proof of misuse.** You usually won't get it in time. Treat reachable as compromised.

## What Crunu does and doesn't do

Crunu does not change values at providers. It can't revoke your Stripe key or create a new AWS access key; you do that in the provider's console or API. **Crunu has no secret scanner** either, so it won't tell you that a value appeared in a commit.

What it does help with is the step after you have a new value. Save it as a new version of the environment, and services started with `crunu run --restart on-change` pick it up and restart with it, without a redeploy:

```sh
crunu run --env payments-api/production --restart on-change -- /opt/payments/bin/server
```

When the leak is a person rather than a file, for example someone leaving with values they had seen, the member removal flow produces a **reissue checklist**: the values they received that are still in use, with a link to where to reissue each one from a recognized service, without showing the values. The [rotation guides by service](https://crunu.com/rotate) cover provider steps, and the [guide to sharing .env files](https://crunu.com/guides/share-env-files-with-a-team) covers keeping values out of the places they usually leak from. For the Git case in detail, see [what to do when a .env file leaks in Git](https://crunu.com/blog/env-file-leaked-in-git).

## Sources

- [GitHub Docs: Removing sensitive data from a repository](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository), checked October 30, 2026.
- [Stripe Docs: API keys](https://docs.stripe.com/keys), checked October 30, 2026.