For many teams, the platform's environment-variable screen is the only place a production secret has ever been written down. Railway says that is the system it saw unusual activity in. On 21 October the platform-as-a-service provider disclosed anomalous activity on systems that store customer environment variables. Its investigation found that an unauthorised party may have accessed encrypted variables and, for some of them, obtained the decrypted contents. Railway asks customers to rotate their variables, including API keys and private registry credentials, and paused deployments while it investigates.
Railway says the impact is limited to a subset of users, who will be notified by email. It has not said how large the subset is. The advice from every source we read is the same: do not wait to find out which side of the line you are on.
What is confirmed
According to The Hacker News and to GitGuardian's analysis, both relaying Railway's disclosure, Railway reports the following:
- The access. An unauthorised third party may have accessed encrypted environment variables and, in some cases, obtained decrypted values.
- The scope. A subset of users, to be notified individually by email.
- What customers should do. Rotate environment variables and private registry credentials, and review service logs for unusual activity, using Railway's guides for AWS, Google Cloud and GitHub.
- What Railway did. It notified upstream providers so they could revoke keys, rotated all of its own bucket credentials and invalidated Railway API tokens. Builds for Pro and Enterprise workspaces were restored first, with Hobby, Free and Trial workspaces still being restored at the time of the report.
- The context Railway gives. It says the incident is likely part of a series of attacks on platform companies, with the ultimate aim of compromising providers of AI inference. That is Railway's own assessment.
What is not known
- How many customers and projects were affected. Railway has not said.
- How the attacker got in. No account of the entry route has been published.
- Whether encryption keys were taken. The reporting does not say, so we cannot tell you how the decrypted values were obtained.
- Whether sealed variables were in scope. GitGuardian notes these cannot be read back through the dashboard, API or command line, but that the disclosure does not say whether they were affected.
- Whether stolen keys have been abused. Railway has not said. The Hacker News relays a researcher's report of cryptocurrency wallets drained when their private keys were stored on the platform; we could not confirm that independently, and Symantec's Dick O'Brien told The Hacker News he saw no evidence it is linked to a separate campaign of AI-key abuse in his data.
- Whether the attack-series attribution is confirmed. It is Railway's claim as reported.
Why “encrypted” is not the end of the sentence
A platform encrypts variables at rest so that a stolen disk or database dump is useless, but the platform must also decrypt them to inject them into your running service. Any intruder who reaches the part of the system that does that can read them the way your application does. Railway's own wording, that decrypted contents were obtained in some cases, is consistent with that.
This is why the advice is to rotate rather than to check. A secret that has been decrypted by someone else cannot be made safe by any later hardening. Only a new value can.
What to do
- Make the list. Export the variables from every Railway project, service and environment you have, including old ones. The command-line tool can dump them; if you do, treat the dump itself as sensitive and delete it afterwards. GitGuardian suggests scanning the dump to prioritise.
- Rotate upstream first, then update Railway. Replace the credential at the provider, such as AWS, Google Cloud, GitHub, a database host, a payment or email provider or an AI provider, then put the new value into Railway and redeploy. Doing it the other way round leaves the old value live longer.
- Order by blast radius. Cloud account keys and database passwords, then payment and messaging keys, then AI-provider keys, signing keys and webhook or OAuth secrets. Anything that can spend money or reach customer data goes first.
- Include the sealed ones. Rotate sealed variables as well, since the disclosure does not say they were out of scope.
- Check for use. Review the logs of each service those secrets reach for sign-ins, API calls and billing spikes from addresses you do not recognise, starting from before the disclosure. If a private key controlled funds, assume it is already in use.
- Revoke Railway-side access. Railway invalidated its API tokens, so create new ones, and review who has access to your workspaces and which deploy tokens exist.
- Reduce the next list. Prefer short-lived credentials issued at run time over long-lived keys in a variable. Give each service its own narrowly scoped key, and keep wallet or signing private keys out of a general-purpose variable store.
The rotation handover
A rotation across ten services means ten new values reaching whoever sets them. In a hurry they get pasted into the team chat or the incident ticket, which is the next place an intruder reads. Send each value once, to the one person who needs it, over a channel that does not keep it.
Where Secretus fits, and where it does not
Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.
It is not a secrets manager or a hosting platform. It does not hold your variables, rotate them with your providers, or tell you whether your Railway projects were in the affected subset. Use the providers' tooling and Railway's guidance for that, and a one-time link for the moment one person gives another a new credential.