Home > Security Guides > How to Rotate Leaked API Keys After a Platform Breach

How to Rotate Leaked API Keys After a Platform Breach

After a platform breach exposes your environment variables, rotate every API key and token in the right order, then check logs for misuse.

m00s3c
November 9, 2026
November 9, 2026

When a developer platform is breached, the stolen data is often not names and email addresses. It is the keys your apps use to reach everything else. Railway confirmed that an attacker decrypted some customer environment variables while hunting for AI provider API keys, Chainstack told customers to rotate node credentials and regenerate API keys, and Zeabur said attackers reached more than 3.2 million environment variable records. If a platform you use sends a notice like that, every secret you stored there is a live risk until you replace it. This guide walks you through rotating them in the right order, checking for abuse, and cleaning up so the same leak cannot repeat.

The key idea: a secret that was ever readable on a breached platform is compromised, even if the vendor says it found no proof of misuse. Rotating is cheap. Explaining a surprise cloud bill or a drained wallet is not.

Step 1: Read the vendor notice and set the scope

Open the platform’s incident notice or postmortem and write down three things: the dates the attacker had access, which data types the company lists (environment variables, API tokens, integration secrets, session keys), and any rotation steps the vendor asks you to take. Our write-ups of the Railway, GitBook and Chainstack incidents show how those notices read. When the notice is vague, assume every secret stored on the platform was exposed.

What success looks like: you have a short note with the exposure window, the data types, and the vendor’s own to-do list.

Step 2: Inventory every secret that lived there

List everything you stored on the platform or passed through it: environment variables, database passwords, cloud access keys, payment keys, AI provider keys, webhook signing secrets, OAuth client secrets, and Git or deploy tokens. Check each project and environment, including old staging and forgotten test projects. For each item, note which provider issued it and which apps use it.

What success looks like: one list with the secret name, the issuer, where it is used, and a column to tick when it is replaced.

Step 3: Rotate the highest risk secrets first

Work in this order: anything that moves money (payment and crypto keys), then cloud account keys, then database credentials, then AI and SaaS API keys, then everything else. Wherever the provider allows it, create the new secret first, deploy it, and only then revoke the old one so your service does not go down. Store each new value in your platform’s secret manager, never in code or chat.

For AWS access keys, the AWS IAM rotation guide uses this sequence. Replace the placeholders with your own user name and key IDs:

aws iam create-access-key --user-name YOUR_USER creates the second key
aws iam get-access-key-last-used --access-key-id OLD_KEY_ID shows whether the old key is still in use
aws iam update-access-key --access-key-id OLD_KEY_ID --status Inactive --user-name YOUR_USER disables the old key
aws iam delete-access-key --access-key-id OLD_KEY_ID --user-name YOUR_USER deletes it once nothing breaks

Because the old key was exposed, do not wait days to see if it is still in use. Deactivate it right after your apps run on the new one.

What success looks like: the old key shows as Inactive or deleted, and your apps still run on the new key.

Step 4: Revoke tokens in each provider’s dashboard

Most providers have a rotate or delete button. Two examples confirmed against their documentation:

Stripe: on the API keys page, open the overflow menu for the key, select Rotate key, pick an expiration, then click Rotate API key. If you choose Now, the old key is deleted immediately, which is what you want for a compromised key. Stripe says you cannot retrieve the new value later, so save it right away.
GitHub: click your profile picture, then Settings, then Developer settings. Under Personal access tokens, open Fine-grained tokens or Tokens (classic), and click Delete next to any token the breached platform could read. Then generate a new one with a short expiration and only the access it needs.

Repeat this for every provider on your list, including AI providers, email senders and analytics tools. If a provider offers no rotate option, delete the key and create a new one.

What success looks like: each old token no longer appears in the provider’s dashboard, and the item is ticked off your list.

Step 5: Check logs for use of the old keys

Rotation stops future abuse. Logs tell you whether abuse already happened. Look at activity during the vendor’s exposure window and afterward:

AWS: aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=OLD_KEY_ID --max-results 50 lists management events for that key. The AWS CLI reference says LookupEvents covers the last 90 days.
GitHub: open Settings, then Security log in the Archives section of the sidebar. GitHub lists actions from the last 90 days.
Stripe: use the overflow menu on a key and choose View request logs.
AI and SaaS providers: check the usage or billing page for spikes, new models, or traffic from regions you do not use.

Treat any request you do not recognize as an incident. Rotate again, change the owning account’s password, review connected apps, and contact the provider’s support.

What success looks like: you can explain every call made with the old keys, or you have escalated the ones you cannot.

Step 6: Find leftover copies of old secrets

Old values often survive in code, config files and Git history. From inside your repository, these commands run on any machine with Git. The first searches the working files, the second searches every commit on every branch, and the third lists the commits that added or removed an exact old value:

git grep -n -I -E "AKIA[0-9A-Z]{16}" finds AWS style key IDs in current files
git grep -n -I -E "AKIA[0-9A-Z]{16}" $(git rev-list --all) searches the full history
git log --all -S"OLD_VALUE" --oneline shows which commits touched that exact value

Because the old keys are already revoked, anything these commands find is no longer a working credential, but clean it up anyway so nobody mistakes it for a live one. For a broader scan, open source scanners such as Gitleaks and TruffleHog look for many key formats at once.

What success looks like: searches return nothing, or only keys you have already revoked.

Step 7: Reduce the damage next time

Use separate keys per app and per environment, so one leak does not open everything.
Grant the minimum permissions. Stripe, for example, recommends restricted API keys for most uses.
Set expirations on tokens where the provider supports it.
Keep production secrets out of shared chat, tickets and screenshots.
Put a reminder on your calendar to review and rotate keys at a regular interval, and whenever someone with access leaves the team.
Use a unique, strong password for every platform account. The BreachNews password generator can help.

What success looks like: your next vendor breach notice becomes a 30 minute checklist instead of a scramble.

Common mistakes

Deleting the old key before the new one is deployed. That causes an outage and tempts people to restore the leaked key.
Rotating only the keys the vendor names. Assume everything stored on the platform was readable.
Forgetting webhook secrets, OAuth client secrets and database passwords. They are secrets too.
Skipping the log check. A rotated key can still have been used last week.
Pasting the new key into code or a chat. That recreates the problem.
Waiting for proof of misuse. Vendors often cannot tell what an attacker actually read.