In this guide
  1. What this checklist is for
  2. 1. Decide who is in scope
  3. 2. Inventory the secrets that environment could see
  4. 3. Create new credentials, deploy, then revoke the old ones
  5. 4. Check for use of the old secrets
  6. 5. Watch for follow-on phishing
  7. Related incidents on One Signal Desk

TL;DR: When keys, tokens or environment variables may have leaked, inventory every secret that environment could see, create new ones, deploy the new values, then revoke the old ones. Do not only “redeploy” old code that still embeds the old secret. Then review logs for use of the old credentials. The vendor’s notice decides who is in scope; this page is the rotation order.

What this checklist is for

Use this after a leaked environment variable, a committed token, a stolen provider key, or malware that could read secrets (including a compromised package). For a vendor incident that also exposed customer records, use this alongside the vendor breach checklist. Broader alerts: security coverage.

1. Decide who is in scope

Start from the vendor’s own statement, not from a rumour.

  • Railway, in its preliminary report on the October 2026 incident, recommended that all customers who signed up before October 21 rotate keys stored on Railway, after environment variables for a subset of workspaces (at most 1.85%, about 100,000 workspaces) may have been decrypted. See our Railway article for the report and any later status.
  • OpenCode said a breach affected 1.4% of OpenCode Console users who had external providers linked, and that it emailed everyone affected. If you use Console with your own provider keys, check that email. See our OpenCode article.
  • PingCAP said an intruder copied TiDB Cloud account, billing and support data and a table of encrypted TiDB Cloud API-key values, and asked customers to rotate those API keys. See our PingCAP article.

If the vendor says you are in the affected set, or you cannot tell, rotate.

2. Inventory the secrets that environment could see

Write down every credential the compromised system, workspace or package could read. Typical categories, drawn from the incidents above and from the LiteLLM 1.107.0 case:

  • API keys and provider tokens (OpenAI, Anthropic, cloud LLMs, payment, email, DNS).
  • Datastore URLs and passwords, object-storage keys, and ORM or dashboard secrets.
  • CI, registry and package-publish tokens; GitHub and GitLab personal or project tokens.
  • SSH keys and cloud access keys on the same host.
  • Session tokens, webhook secrets and “project tokens” the vendor tells you to replace.

On Railway, the recommendation covered keys stored as environment variables, and API and Project Tokens created before the incident stayed invalidated, per our article. Follow that article for the current token advice.

3. Create new credentials, deploy, then revoke the old ones

Work in this order so you do not lock yourself out:

  1. Create the new key, token or password in the provider’s console.
  2. Put the new value in the config or secret store you actually run from.
  3. Deploy a new release that reads the new value. One Signal Desk advice, based on Railway’s warning that redeploying pre-incident code errors, is to deploy a new commit rather than redeploying old code that may still carry the old secret.
  4. Revoke or delete the old credential once the new release is healthy. Leaving the old key valid is the usual failure.
  5. Repeat per provider. Do not wait for a quiet weekend if the vendor has already said the secret may have been read.

4. Check for use of the old secrets

  1. Review provider audit logs, billing and usage for the window the vendor names (or from the first possible leak until the old key was revoked).
  2. OpenCode’s advice, in our article, was to review provider usage and billing for the linked keys. PingCAP asked customers to check access logs and review members and roles.
  3. If you see use you cannot explain, treat the connected accounts as compromised: rotate again, review persistence, and follow the provider’s abuse process.

5. Watch for follow-on phishing

After a customer-data copy, attackers often send messages that quote a real name, ticket or order. PingCAP explicitly asked customers to watch for phishing emails that pose as PingCAP. For the same pattern after a vendor website or identity breach, see the vendor breach checklist.

Sources

Last checked: Nov 10, 2026, 1:16 p.m. Manila (UTC+8). Method: We built this type-level checklist from the live One Signal Desk articles linked above (HTTP 200 on Nov 10) and from the vendor steps those articles already quote. Incident status lines can move; re-read the linked articles before you act. Thumbnail is a reuse-licensed image, credited with its license under the picture. No HowTo or FAQ schema. No affiliate links. How we work.