Railway: your .env went for a ride without you

Railway, a popular platform-as-a-service, says that on the morning of October 21, 2026 it detected unusual activity in the systems that store customer environment variables. Its investigation so far says an unauthorized party may have accessed the encrypted variables and, for some of them, obtained the decrypted contents. On Railway, environment variables are where apps keep their API keys, database passwords and registry credentials, so this is effectively a secrets store.

Railway believes the intrusion is part of a recent series of attacks on platform companies whose goal is to get at AI inference providers. It says it has asked those upstream providers to revoke keys proactively. It has not named them, but its own follow-up guides cover OpenAI, Anthropic, Grok and OpenRouter usage checks.

What Railway did on its side

• Paused all builds and deployments, Enterprise included, from the morning of Oct 21. Builds came back for Enterprise around 03:30 UTC on Oct 22, with other plans following in stages.
• Invalidated OAuth sessions (users get logged out).
• Reset every storage bucket’s S3 credentials and the GitHub tokens Railway held for account connections, and removed GitHub tokens stored as registry credentials. These resets show in workspace audit logs under “Railway Staff”.
• Asked upstream (unnamed) providers to revoke keys.

Railway can’t rotate your third-party secrets for you: the Stripe key, the OpenAI key and the database password in your variables are yours to roll. And because containers only read variables at startup, any rotation needs a redeploy, which was impossible while builds were paused.

Why L4

Railway says the impact “may be limited to a subset of users”, yet tells all users to rotate. It confirms that decrypted secrets were obtained for at least some customers. A breach of a multi-tenant secrets store at a large PaaS is a mass credential leak, and each leaked key opens a different downstream system. That is L4. It would move up if large-scale abuse of the stolen keys were confirmed.

What’s still unclear

• How the attacker got in (stolen employee or service credential, vendor, bug) and when the intrusion actually started. Railway has only said when it detected it.
• How many customers or variables were affected, and which ones were decrypted. Railway will email confirmed accounts, but has given no number.
• How encrypted values became readable, and therefore whether rotating secrets alone closes the path the attacker used.
• Whether the outage that started at 07:24 UTC was caused by the attack or by the response. Railway’s status page tracks both under one incident but doesn’t say.
• Misuse. No public report yet confirms that a stolen Railway secret was used. Absence of reports is not evidence of absence: check your own provider logs.