Railway breach: rotate every secret, step by step (Oct 2026)

Railway disclosed on 21 October 2026 that an unauthorized party may have accessed encrypted environment variables and decrypted some of them. Railway recommends all users revoke and reapply sensitive variables stored on Railway. Replace each secret at the service that issued it, update Railway, and redeploy. The order differs by secret type, so follow Railway's guide for each.

Who is affected?

Railway's preliminary report says a subset of its customers had encrypted secrets exposed, and it recommends rotation for all users as a precaution. The secret types in its own notice include API keys, database credentials and registry credentials. Railway's status page says that as of 18:57:54 UTC on 23 October it had completed notifications to users whose workspaces met its increased-risk criteria. Railway still recommends rotation for everyone else.

Railway's preliminary report puts the upper bound at 1.85% of all workspaces with some environment variables potentially compromised. Its first disclosure gave no number, and TechCrunch reported on 22 October that Railway did not say how many users were affected. Railway also says more than 100,000 users were affected by upstream provider reset requests, so a key revoked by a vendor does not mean your workspace was among those with variables potentially compromised. We do not claim that every customer's secrets were decrypted. Railway does not claim that either.

Why is changing it in Railway not enough?

Railway holds your copy of a secret. The provider holds the real one. If you edit a variable in the Railway dashboard, the old key still works at the provider until you revoke it there. The order of creating, revoking and deploying differs by secret type, so follow Railway's guide for each one:

• AWS keys: Railway's guide has you deactivate the exposed key in the IAM console yourself, create the replacement, edit AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in Railway, deploy the staged change, then review CloudTrail. Railway does not do the AWS step for you. For Google Cloud keys, see Railway's GCP guide.
• GitHub registry tokens: Railway's guide deletes the old token on GitHub first, creates a replacement with the read:packages scope, saves it in the service's registry credentials and redeploys.
• Other secrets: use the issuer's own instructions, then check its logs. The general order for rotating after any breach covers the rest.

Railway also warns that a new value does nothing until the service redeploys. Its credential reset guide says services using bucket credentials need a redeploy to pick them up.

A second trap is an email from a vendor saying your key was revoked. Railway says that does not imply your credentials were impacted. Its preliminary report says Railway sent providers a list of potentially decrypted keys and some vendors requested that all keys be revoked, so some revocations are precautionary.

How do I rotate every secret?

What do I list first?

• Open every project and every environment (production, staging, preview). Variables are per environment.
• Check shared variables in project settings as well as service variables.
• Write down, for each secret, the issuer that can revoke it.
• Include secrets pasted into a service as plain values, build settings, and registry credentials.

In what order do I rotate?

Railway's preliminary report also recommends removing public network access to databases.

How do I redeploy and recover Railway itself?

Railway invalidated all Railway API and project tokens on 22 October, so CLI and CI jobs that used old tokens fail until you create new ones. Railway's recovery guide (23 October) says:

• Reconnect GitHub in account settings and check the Railway GitHub App still has access to the repository.
• Disconnect and reconnect the repository on the service, then deploy the latest commit. Commits pushed during the pause were not queued.
• For CLI deploys, log out, log in, and link again. For CI, create a replacement token with the same scope and update your CI secrets.
• For storage buckets, redeploy each service that uses them so it picks up the new credentials.

If deploys still fail, Railway's recovery guide asks you to email support@railway.com with the project, service, environment, failed deployment ID, build log error and deploy method.

What do I ask Railway in writing?

For workspace [your workspace name], were any of our environment variables identified as accessed or decrypted? If you cannot tell, please say so. Please also confirm whether source code for our connected repositories is in scope, and send any indicators we should search our logs for.

Keep the reply. Railway's report says it cannot yet tell which variables were decrypted, so "we cannot tell" is a plausible honest answer.

Am I affected? A three-state self-test

Was anything exploited, and what should I look for?

Railway says an unauthorized party may have decrypted some variables, and that it believes the incident is part of a series of attacks on platform companies aimed at AI inference providers, which it notified to revoke keys (disclosure). The root cause and entry point were not published at our check on 28 October 2026. We cannot say how any individual customer was affected.

Look at the issuer of each key for use you do not recognise, from before 21 October to today:

• Cloud: calls your application never makes, new users or access keys, activity in regions you do not use. Railway's AWS guide lists specific CloudTrail checks.
• Databases: open sessions you do not recognise, accounts you did not create, rows changed outside normal writes. Railway's MySQL guide covers these.
• AI and payment providers: usage spikes and charges in the provider's own dashboard.
• Source control: the audit log and installed apps on GitHub, GitLab or your registry.

What does the free scan add?

The free scan reads what your site serves from outside. It looks for API keys and tokens in shipped bundles, .env and backup files, and databases and services reachable from the internet. It is a lookup. It cannot see inside Railway, and it cannot tell you whether a rotated key was ever read. After you rotate, it can show whether the new secret now sits in a public bundle or whether a database is still open to the internet.

This incident is one of several in the same week. A running tracker of the month's incidents lists the others, and a ranked checklist for this week sorts them by what to do first. If your Railway apps run PHP, see the PHP runtime flaw write-up too: rotating secrets does not patch the runtime. Two other platform breaches the same month ask for the same rotation: TiDB Cloud's stolen credentials and the Zeabur shutdown. If you run LiteLLM as a gateway, the compromised 1.107.0 release puts the AI provider keys it holds at risk too. More like these are in the other incident write-ups.