Railway asks all users to rotate their secrets after attackers read some decrypted environment variables

Railway, a platform where developers deploy and run their applications, disclosed on October 21, 2026, that an unauthorized third party may have accessed encrypted environment variables belonging to its customers. For some of those variables, the attacker obtained the decrypted contents. Environment variables are where applications usually keep API keys and database passwords, so the company recommends that every user replace everything stored there.

What Railway says happened

The company says it detected anomalous activity that morning in the systems that hold customer environment variables. Railway believes the attack is part of a series aimed at platform companies, with the goal of compromising AI inference providers, the services that run models for paying customers. It says it has asked those upstream providers to revoke all keys.

Railway's initial analysis suggests that only a subset of users was affected. It has not said how many, or how the attackers got in. The company paused all deployments while it investigated and says it will email affected customers once it confirms who they are.

What users have to do

The disclosure and two recovery guides published on October 23, 2026, add up to the following steps:

• Replace every environment variable stored in Railway, including API keys and private registry credentials, and check the logs of those services for unusual activity.
• Log in again, because all login sessions were revoked. Use the same Gmail, GitHub account or email address as before, since a different identity creates a new, empty account.
• Reconnect GitHub, because those connections were revoked too, and then trigger Deploy Latest Commit again.
• Create new RAILWAY_TOKEN and RAILWAY_API_TOKEN values for CI pipelines, and run railway logout and railway login on the command line.

Changes that never shipped

Commits pushed while deployments were paused were not queued. According to Railway's guide, a service keeps running its last successful deployment until someone triggers a new one. A fix pushed during the outage may therefore not be live, even though the commit shows up in the repository.