Railway, the cloud platform that millions of developers use to deploy apps, APIs and databases, is telling every customer to rotate their secrets after an intruder got into the systems that hold customer environment variables. The company says some of those variables, which often contain API keys and database passwords, may have been decrypted by the attacker.
What happened
In a security disclosure dated Wednesday, October 21, 2026, Railway said it had spotted unusual activity that morning on the infrastructure where it stores customers' environment variables. Its investigation so far suggests an unauthorized party reached the encrypted variables and, in some cases, managed to obtain their decrypted contents.
Railway believes the intrusion is one piece of a wider campaign against platform companies, with the end goal of compromising AI inference providers, the services that run AI models and return results to applications hosted on Railway. The company says it warned those upstream providers directly and asked them to revoke all of their keys as a precaution.
As a containment step, Railway paused all builds and deployments, which meant customers could not ship new versions of their apps for a while. Its status page shows that by 08:44 UTC on October 22 (4:44 AM EDT), builds were back for Pro and Enterprise workspaces, while Hobby, Free and Trial workspaces were still waiting, with restoration planned in that order.
Who is affected
Railway hosts more than 16 million services for around 4.8 million users, according to BleepingComputer. The company's early analysis points to a limited subset of accounts, but it has not said how many, and it is asking all users to act as if they could be affected. Railway says it will email customers directly once it confirms that their accounts were compromised.
Technical details
Environment variables are where most cloud apps keep their configuration and credentials, such as third-party API keys, database connection strings and private container registry logins. Anyone holding decrypted copies could log in to those outside services as the victim, so the risk reaches well beyond Railway itself.
Railway did not wait for customers to clean up everything on their own. In a follow-up guide published October 22, it said it had already reset two kinds of credentials on users' behalf:
- Storage bucket keys: the S3-style access key ID and secret key for every bucket in every environment were invalidated and regenerated. Bucket names, endpoints and stored objects are unchanged.
- GitHub tokens: the tokens Railway held for GitHub account connections were invalidated, and GitHub access tokens saved as registry credentials on services were removed from Railway. Railway warns that those removed registry tokens still work on GitHub itself until the owner revokes them.
These resets show up in workspace audit logs as actions by Railway staff, so admins can tell them apart from changes made by their own team. No CVE has been assigned, and Railway has not said how the attacker got in.
What you should do
- Rotate every secret stored in Railway: API keys, database passwords, tokens and private registry credentials. Generate new values at the provider that issued them, not only in Railway.
- Revoke old GitHub tokens that were stored as registry credentials, then reconnect GitHub to Railway.
- Redeploy services that use storage buckets so they pick up the new keys, since containers only read variables when they start. Replace any pasted bucket keys with Railway reference variables, and update local tools or CI jobs that used the old keys.
- Review logs for your Railway services and for every outside provider whose keys were stored there, looking for logins, API calls or spending you don't recognize.
- Export your audit log entries for your own incident records, because retention depends on your plan.
- Watch for Railway's email and its status page for confirmation of affected accounts and further updates.
0 Comments