Last updated: 23 October 2026.
We update this page when Railway publishes its full incident report or changes its guidance.
On 21 October 2026 Railway, a cloud platform for deploying apps and databases, told users that an unauthorized third party may have read encrypted environment variables and, for some of them, obtained the decrypted contents. Railway says these variables may hold API keys, database credentials and registry credentials. The risk reaches every customer downstream, which fits the definition of a supply chain attack: a service you trust held your secrets.
What Railway Has Said So Far
Railway’s security notice says it detected anomalous activity on systems that store customer environment variables. It believes the impact may be limited to a subset of users, but it asks all users to act. It will email customers it confirms as affected.
Railway also says it believes this is part of a series of attacks on platform companies, aimed at compromising AI inference providers. It notified those upstream providers so they could revoke keys early. The notice does not name an actor.
Railway’s status page and its security guides list the steps it took itself. It invalidated OAuth sessions on 21 October and rotated all storage bucket credentials. It reset the GitHub tokens it held and invalidated all API tokens and Project Tokens created before the incident. If you use the Public API or the CLI, create a new token.
Deployments were paused during the response. The status page shows builds enabled for Hobby, Pro and Enterprise workspaces at 21:59 UTC on 22 October. Free and Trial workspaces were still to follow, and new signups were paused. Railway says a full incident report will come on its blog. Until then, our Railway security incident timeline tracks each status update.
Where Your Secrets Live on Railway
Start by listing every place a secret can sit. Railway’s security guides point to these:
- Service variables and shared project variables, including pasted connection strings.
- Database credentials such as DATABASE_URL, DATABASE_PUBLIC_URL and REDIS_URL.
- Cloud keys: an AWS access key pair or a Google Cloud service account key file.
- Payment and AI keys, for example Stripe, OpenAI, Anthropic, Grok and OpenRouter.
- Private registry credentials, including a GitHub personal access token used to pull from ghcr.io.
- Copies outside Railway, such as local development, CI jobs and BI tools that use the public database URL.
In What Order to Rotate
Railway’s guides do not rank the steps. The order below is ours: keys that can spend money or reach other systems go first, because they work from anywhere. Create the new value first, then deploy it, then retire the old one.
- Save evidence. Export the logs you will need before you delete anything. Railway’s GitHub guide says to export the audit log before you revoke anything, and its Stripe guide says to export evidence before you clean up. Audit log retention in a Railway workspace depends on your plan.
- Cloud, payment and AI keys. Replace each one at the provider:
- AWS: create a second key, then deactivate the old one instead of deleting it, so you can reactivate it briefly if a forgotten service breaks.
- Google Cloud: create a new service account key and disable the old one with the gcloud CLI, because the console cannot disable keys.
- Stripe: rotate the key and choose Now as the expiry for a confirmed leak, or a window long enough to redeploy for a precautionary rotation. Rotate every other secret and restricted key on the account too, and update any webhook signing secret you rotate.
- OpenAI and Anthropic: delete the key and create a new one. Grok and OpenRouter: disable the key, which keeps its history for review, then create a new one.
- Database passwords. In the Database tab, use Regenerate. Do not edit the password variable by hand or run ALTER USER yourself, because that leaves the database and its variables out of sync.
- Regenerate restarts the database and drops every open session.
- Then redeploy every service that references it.
- Tokens and registry credentials. Reconnect GitHub in Account Settings. Delete old ghcr.io tokens on GitHub, create a new one with the read:packages scope and add it to the service. Create new Railway API tokens.
- Everything else. Replace pasted values with reference variables, so the next rotation reaches every service by itself.
Containers read variables only at startup. A service keeps using the old value until you redeploy it, so a rotation is not finished until each consumer has restarted.
What to Check in Your Logs
A rotation stops future access. It does not tell you whether the old secret was used. Railway’s guides give these checks per system.
- AWS: search CloudTrail event history by the access key ID, in every Region. Look for RunInstances, CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole and PutBucketPolicy. Download the IAM credential report and compare Cost Explorer with the previous month.
- Google Cloud: in Logs Explorer, filter on the service account’s principal email. Look for new service accounts or keys, IAM bindings, Compute Engine instances, storage buckets and project SSH keys. Compute, GPU and Vertex AI charges are the common targets.
- GitHub: read your security log (kept 90 days) and your organization audit log (kept 180 days). Review OAuth apps, SSH keys, personal access tokens, deploy keys and webhooks. An attacker with push access can add a webhook or secret that outlives a password reset.
- Stripe: open the request logs of the old key. Review charges, refunds, payouts, bank accounts, webhook endpoints and team members you did not add.
- PostgreSQL: after the rotation, list sessions in pg_stat_activity. Any session you do not recognize connected with the new password, so find out where it got it. Also check deploy logs for password authentication failed errors.
What We Checked and What Is Still Unknown
Railway has not said how many accounts were affected, how the party got in, or who is behind it. The notice also does not say whether the earlier platform outage on 21 October is linked.
We ran three outside checks on 23 October. A GitHub repository search found no proof-of-concept or leaked-data repository about this incident. An X search found about 107 unique posts since 21 October, with five linking to Railway’s blog, though the pull was capped and older posts may be missing. Our dark web check found no mentions of railway.app or railway.com since 20 October.
Next Steps for Your Security Team
Treat platform-held secrets as third-party risk. Keep a list of which vendors hold which of your credentials, and who can rotate them. Our supply chain attack and vendor risk use case shows how to track that outside access.
Public databases are the quickest wins to close. Railway’s guides say to remove public access when nothing outside the project needs it. Also, external attack surface management can show which of your endpoints are reachable from the internet.
AI keys deserve a second look. Our LiteLLM 1.107.0 response checklist covers a compromised AI gateway release whose malware went after model provider keys. For the wider habit of watching for exposed secrets, see our glossary entry on leaked credentials.