Rotate secrets after a breach: order, steps and checks

To rotate secrets after a breach, list every credential the breached system could read, then for each one revoke it with the service that issued it, issue a replacement, redeploy and restart whatever uses it, and check the old one now fails. Do this broadest key first. Editing a variable in your host's dashboard is only the middle step.

This is the runbook for any host or tool breach, with the October 2026 cases as examples. The running list of incidents is in the October incident roundup; the short version is a one-week action list. More like this is in the other secrets and supply-chain guides.

Which secrets do I have to rotate?

Every secret the breached system could read, and every secret a breached secret could create.

Railway's disclosure names API keys, database and registry credentials, and there is a Railway-only walkthrough. Zeabur adds signing and encryption keys; what Zeabur customers should do now is on its own page. LiteLLM adds the cloud role of the host and any secret in the environment of any process on it, with a separate page for anyone who ran version 1.107.0. TiDB Cloud users can use the TiDB-specific rotation list.

The test is simple: did you paste the value into the breached platform, or could a process on the breached machine read it? If yes, it is in scope whether or not the provider has emailed you. Railway says a vendor's revocation notice does not by itself mean your credentials were affected (preliminary report). Its status page adds that workspaces outside the groups it had notified were not ruled out (23 October 2026).

What do I rotate first?

Broadest first. This ordering is our judgment, built on the principle in OWASP's secrets management cheat sheet that you revoke and rotate first and clean up after.

Why is changing the variable in the dashboard not rotation?

A secret lives in three places: the service that issued it, the platform variable that stores it, and the running process that loaded it. Rotation means all three change. A dashboard edit changes the middle one.

Three vendor reports describe the gap. Zeabur says changing the environment variable does not change the database password, so you change the password inside the database. Railway says regenerating a PostgreSQL credential restarts the database, and every dependent service keeps the old password until it is redeployed. Railway also removed stored GitHub registry tokens from services and says to revoke the old token at GitHub too, since it may have been exposed.

Should I revoke first or create first?

It depends on whether you think the old key was read. The sources differ on order because they answer different situations.

In a breach, the first row is the default. An overlap window is time in which the old key still works for whoever holds it.

What did each October 2026 breach tell owners to do?

Each report is preliminary and written by the vendor. They show what customers were told to do, and where the gotchas are.

Railway's preliminary report recommends that every customer who signed up before 21 October rotate keys stored there, and says its final forensic report was still pending at our 24 October check. Zeabur dates its wind-down to 1 to 31 December (Zeabur notice), so anything left there needs a migration plan as well as a rotation.

What is the runbook, step by step?

Work in this order.

• List every secret. Platform variables, CI secrets, .env files on servers, tokens in databases, and secrets someone typed into an SQL editor or a chat. Note who issued each.
• Preserve evidence. Export audit logs from the platform, GitHub and cloud account before you revoke anything. The FTC tells businesses not to destroy forensic evidence while remediating, and Railway's GitHub guide says to export the log first.
• Clean the machine, if the machine ran malicious code. See the LiteLLM section below. Rotate from a clean system.
• Revoke at the issuer. The cloud console, the payment dashboard, the AI provider, GitHub. GitHub calls revoking with the provider the most important step. If the secret was committed to a repository, revoke first and clean history second.
• Change database passwords inside the database. Then update every consumer.
• Redeploy and restart. Anything that loaded the old value at start still holds it.
• Prove it. The old credential must fail against the provider. The new one must work. Check logs for authentication failures from services you forgot.
• Hunt what was left behind. See the next section.
• Write it down. Date, what was rotated, who did it, what evidence you kept.

What do I check for misuse?

Use the issuer, because the breached platform's own logs are the weakest record. Look at usage grouped by key and the issuer's audit log. For AWS, LiteLLM suggests searching CloudTrail for GetCallerIdentity calls from the host's role, then for use of its credentials from outside your infrastructure. For GitHub, Railway's guide points to the security log (90 days) and the organization audit log (180 days).

For PostgreSQL, Railway's guide suggests checking pg_roles for unexpected roles and pg_stat_activity for sessions you do not recognize after the password change. PostgreSQL does not log successful connections by default, so a quiet log proves little.

What can survive a rotation?

Anything the attacker added with a stolen secret. Railway's GitHub guide warns that an attacker with push access could add a webhook or secret that outlives a password reset. Check deploy keys, webhooks, repository secrets, collaborators and authorized OAuth apps. Zeabur tells owners of affected servers to look for SSH keys they did not add, unfamiliar privileged accounts and cron entries, and prefers a rebuild.

What if the breached thing ran code on my machine?

Clean first, then rotate. LiteLLM's report lists the order: confirm exposure, do not start Python or pip in the affected environment, remove the startup files, stop the background process, rebuild the environment pinned to an earlier release, and only then rotate. If the host had outbound internet while the bad version was installed, assume the secrets left. A new key created on a machine that is still running the stealer is a new leaked key.

What does rotation not fix?

Data already read. Zeabur's report says rotation does not invalidate data that was already read, so secrets, hashes and tokens stored in a database need replacing too. Session tokens, password hashes and API keys held in a table are in scope.

It does not answer the notification question either. If customer data sat in a store the attacker could read, the FTC's guide points to breach notification laws and law enforcement. That is a legal question for you or your counsel.

What do I ask the host or vendor?

Which of my stored secrets were readable in the incident, and in what form? Please tell me the date range of the exposure, and whether my account or workspace was among those you notified or ruled out.

Which credentials did you rotate on my behalf, on which dates, and where in my audit log do those entries appear? Which ones do I still have to replace myself?

If the answer to the first question is "we cannot say", rotate everything in scope. See who is responsible for patching and fixing for the wider split of duties between you and a host.

What can a scan add?

Red's free scan looks from outside for API keys and tokens in shipped bundles and for exposed .git and .env files. That finds secrets in places the public can reach. It cannot see variables held inside a hosting platform, so it cannot tell you whether a rotation is complete.