How to rotate leaked API keys

Sooner or later you'll read "rotate all your secrets." Maybe your key showed up in a public repo. Maybe a tool you use had a breach. Here is how to do it in the right order. You lock the attacker out without taking your own app offline.

Why this keeps happening

In October 2026 there were two big "rotate everything" moments on the same day:

• Railway, a hosting platform, said on 21 October that an unauthorized third party "may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents." It said the impact may be limited to some users. Still, it asked all users to rotate every env var stored there, as a precaution (Railway disclosure).
• LiteLLM, a popular Python library for calling AI models, had a bad release, 1.107.0. It was on PyPI for about two hours and in some Docker image tags for about two and a half hours. It held malware built to steal cloud keys, env vars and AI tool settings. Any machine that installed it should be treated as compromised (LiteLLM incident report, OSV).

Users did nothing wrong in either case. They still had to rotate.

Step 0: Know when to rotate

Rotate a key if any of these is true:

• It was ever in a public repo, even for a minute, even if you deleted the commit.
• It shows up in your frontend JavaScript. Anyone can open DevTools and read it.
• A service that stores it says it may have been exposed.
• A machine that had it installed a bad package.

Not sure? Rotate. A new key costs a few minutes. A stolen one can cost much more.

Step 1: Make a key list

You can't rotate what you can't find. For each secret, write down:

• What it is. For example, the Supabase service key, Stripe secret key, OpenAI key or database URL.
• Where it is stored. A .env file, your hosting dashboard, CI settings, a teammate's laptop.
• What uses it. Which app, function or worker reads it.

Tip: ask your AI tool to do the first pass. "List every secret this project uses, where each one is read in the code, and where it's set."

Step 2: Clean the machine first (if it was infected)

If a key leaked because a machine ran malware, fix the machine before you rotate. If you don't, the new keys get stolen too.

• LiteLLM warned: "Don't start with pip install." Any Python start on an affected machine runs the malware again, "and that includes running pip." Its advice: delete the bad files, reinstall pinned to 1.106.2 (rebuilding from scratch is better), then rotate everything the machine could reach (LiteLLM).
• In the October 2026 tensorlake npm attack, the malware could, in some cases, install a monitor that deletes your home folder once a stolen GitHub token is revoked. Researchers said to remove that monitor before you revoke any token (Checkmarx).

If a whole machine may be compromised, the safest path is to rebuild it from a clean image.

Step 3: Create the new key, then swap it in

1. Create a new key in the provider's dashboard. Many providers let two keys work at once, so your app keeps running while you switch.
2. Update every place on your key list that uses it.
3. Redeploy. Most apps read env vars only when they start. Railway says it plainly: "Containers read variables only at startup, so every service that uses the credential must be redeployed" (Railway Redis guide).
4. Test that the app still works with the new key.

Step 4: Kill the old key

Now revoke or delete the old key. Until you do, the attacker can still use it. A new key alone doesn't lock anyone out.

Step 5: Look for damage

• Check the provider's usage page for spikes you didn't cause.
• Check your logs for logins or requests you don't know. Railway's Redis guide, for example, says to list connected clients and look for addresses you don't recognize.
• For AI provider keys, set a spending limit if the provider offers one. Then a stolen key can't run up a huge bill.

Step 6: Make next time faster

• Use references, not pasted copies. Railway notes that services using variable references pick up a new value on their next deploy. Services with a pasted value need a manual edit (Railway bucket guide).
• Pin your versions. Avoid latest tags and unpinned installs in production. In the LiteLLM case, people who installed an unpinned version or ran the latest image during the window were affected.
• Keep secrets out of the frontend. Server-only keys, like a Supabase service key or Stripe secret key, should never ship in your JS bundle.
• Keep .env out of git. Add it to .gitignore before your first commit.

FAQ

I deleted the commit with my key. Am I safe?
No. Git keeps history, and anyone who cloned or scraped the repo may already have it. Rotate the key.

Do I need to rotate my Supabase anon key?
The anon key is meant to be public. Your safety depends on Row Level Security being on and correct. The service key is different. It must never be public, and you should rotate it if it leaks. See Is the Supabase anon key safe to expose?

How often should I rotate keys if nothing leaked?
There's no single rule. Practice once so you know how long it takes. Rotate right away when anything in Step 0 happens.

Based on the linked Railway, LiteLLM, OSV and Checkmarx reports as of 22 October 2026. VibeGuard is independent and not linked to any of them.