Railway breach: rotate every secret in your app

Updated Oct 23, 2026 · For apps built with Cursor, Lovable, Bolt, Replit or v0

Short answer: if any secret ever sat in a host that was breached, treat it as public. Revoke or roll it at the provider that issued it, put the new value in your environment, redeploy, and confirm the old one is rejected. Deleting the variable from your host is not enough.

What happened

On Oct 21, 2026, Railway disclosed that an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents. Railway recommends that all users roll every environment variable, including API keys and private registry credentials, and review service logs for unusual activity. BleepingComputer's report covers the timeline. The checklist below works for any host, not just Railway.

Step 1: make a list of every secret

Export or copy the variable names (not values) from every service and environment, including preview and staging. Then search your repo for anything that reads them:

grep -rhoE "process\.env\.[A-Z0-9_]+|import\.meta\.env\.[A-Z0-9_]+|os\.environ\[?\.?(get\()?['\"]?[A-Z0-9_]+" . \
  --include=*.{js,ts,tsx,jsx,py} | sort -u

Vibe-coded apps often have keys you forgot about: an AI provider key, a payments key, an email API key, a database URL, a storage bucket credential, and an OAuth client secret.

Step 2: rotate the dangerous ones first

1. Payments: roll your secret key and webhook signing secret in your payment provider's dashboard (Stripe supports rolling keys directly).
2. AI providers: create a new key, then delete the old one. Check usage pages for spend you don't recognize.
3. Database: change the database password and any service-role or admin keys. On Railway's Postgres template, Railway's rotation guide uses the Regenerate button and then a redeploy of every service that uses it.
4. Cloud and storage: deactivate old access keys and issue new ones.
5. Everything else: email, analytics, error tracking, OAuth client secrets, deploy tokens and registry credentials.

If you have time and the key is not known to be leaked, do it with no downtime: create the new credential, update the variable, deploy and verify, then revoke the old one. If you think it's already leaked, revoke first.

Step 3: redeploy and prove the old key is dead

Containers read variables at startup, so redeploy every service that uses a changed value. Then test the old value directly. For example, with an old OpenAI-style key:

curl -s -o /dev/null -w "%{http_code}\n" https://api.openai.com/v1/models \
  -H "Authorization: Bearer OLD_KEY"

You want a 401. A 200 means the old key still works and someone holding it can still use it.

Step 4: check you aren't leaking keys anyway

Rotation does nothing if the new key also ends up somewhere public. Two quick checks on your own app:

# 1. Secrets in your live frontend JavaScript
curl -s https://yourapp.com | grep -oE 'src="[^"]+\.js"' | cut -d'"' -f2 \
  | while read f; do curl -s "https://yourapp.com$f"; done \
  | grep -oE "sk-[A-Za-z0-9_-]{20,}|sk_live_[A-Za-z0-9]{20,}|service_role|AKIA[A-Z0-9]{16}"

# 2. Secrets anywhere in your git history
gitleaks detect --source . -v
trufflehog git file://. --only-verified

Any secret that was ever committed stays in git history, so rotate it even if a later commit deleted it. Only test apps and repos you own.

Step 5: look for misuse

Review service logs and provider dashboards for the days around the incident: unexpected API usage or spend, new users or admins, database connections from unknown IPs, and new webhooks or OAuth apps. Turn on spend limits and usage alerts where your providers offer them.

Common questions

Do I need to rotate my keys if I host on Railway?

Railway's Oct 21, 2026 security disclosure recommends that all users roll every environment variable stored in Railway, including API keys and private registry credentials, and review service logs for unusual activity, even though the impact may be limited to a subset of users.

What order should I rotate secrets in?

Start with keys that can spend money or reach user data: payment secret keys, AI provider keys, cloud keys, database passwords and service-role keys. Then rotate webhook signing secrets, OAuth client secrets, and third-party tokens such as email or analytics keys.

Is deleting the old variable enough?

No. Removing a variable from your host does not stop anyone who already copied it. You have to revoke or roll the key at the provider that issued it, then confirm the old value is rejected.

How do I rotate without downtime?

Create the new credential first, update the environment variable, redeploy and verify, then revoke the old one. If you suspect the key is already leaked, revoke first and accept a short outage.