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

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). 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.

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.
2. Check what the old value was used for. Providers such as Stripe show request logs per key (Stripe). 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:

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 cover provider steps, and the guide to sharing .env files 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.

Sources

• GitHub Docs: Removing sensitive data from a repository, checked October 30, 2026.
• Stripe Docs: API keys, checked October 30, 2026.