Railway Security Incident: Impact, Timeline and Credential Rotation Guidance

Railway’s October security incident exposed encrypted environment variables in a subset of customer workspaces and forced the platform to pause new builds while its engineers contained the intrusion. The company says existing applications stayed online throughout, but customers who stored credentials on Railway before October 21 should rotate them as a precaution.

Railway’s preliminary account describes an intrusion that began with suspicious activity in its infrastructure and expanded through internal systems, including its build environment. The company says evidence points to an attempt to obtain AI provider keys, apparently for model distillation. Its investigation is still underway, so the precise scope and whether source code was accessed remain unresolved.

The company’s initial disclosure was published October 21. This follow-up covers events through October 22 and says Railway engaged outside incident response specialists. Railway says it will publish another update when its forensic work is complete. The details below reflect its preliminary findings, which may change as that work continues.

How the incident unfolded

Railway places the activity between October 20 at 13:58 UTC, when monitoring alerted its on-call engineer to elevated latency, and October 22 at 03:32 UTC, when the company confirmed the intruder no longer had access to internal systems. At 19:53 UTC on October 20, investigators found evidence that the attacker might expand access across multiple parts of the platform in parallel. That discovery changed the response from addressing a suspected build-system weakness to isolating a broader intrusion.

Engineers halted build pipelines, restricted access to affected infrastructure and introduced monitoring and credential controls. They later found evidence that the attacker had retrieved encrypted secrets. The initial assessment was that the attacker could not decrypt them at that point. However, access to credentials in Railway’s continuous integration environment enabled the attacker to decrypt artifacts containing additional API access.

On October 21, Railway found database evidence of an unauthorized query involving encrypted environment variables. Investigators say a subset had been decrypted using a combination of compromised credentials. Because the variables were protected with envelope encryption, the query alone did not reveal exactly which customer keys were affected. Logs from the attacker’s payloads showed names of API keys being sought.

At 09:25 UTC on October 21, Railway began contacting providers and asking them to revoke potentially exposed credentials. The company also invalidated user sessions, shared customer guidance and rotated credentials. It says the attacker’s access was confirmed to have ended on October 22 at 03:32 UTC. Railway then rebuilt internal systems with new credentials and fewer dependencies, restoring Enterprise and Pro builds before bringing other deployment tiers back. By later on October 22, the company reported that API access and deployments across its plans had been restored; some secondary features were returning gradually.

The response disrupted parts of Railway’s control plane and developer workflow. Customers experienced interrupted builds and deployments, as well as periods when the dashboard, API, command-line interface and support tools were unavailable. Railway says already-running customer services remained online, and that builds for all tiers had resumed by the time of its report.

What Railway says about exposure

Railway says its system separates sets of keys so that compromise of one set should not expose the entire platform. Its preliminary estimate is that environment variables in at most 1.85% of workspaces could have been exposed. The company described that as roughly 100,000 workspaces. This is a ceiling for potential exposure, not a count of confirmed compromised credentials.

Railway says it notified customers with confirmed impact and was contacting additional customers it considered at higher risk. Its assessment of risk reflects the attacker’s apparent interest in workspaces with many environment variables or a high concentration of AI provider keys. The number of customers contacted proactively is greater than the 1.85% estimate, because investigators could not identify every variable that may have been decrypted.

The company sent providers lists of potentially affected credentials and, in some cases, asked them to revoke every key Railway stored for their service. It says it shared all keys present on the platform with some providers, including GitHub and SpaceXSI, as a precaution. Railway worked with GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI and Stripe, among others. As a result, a provider’s revocation notice does not by itself establish that a customer’s key was exposed.

Railway says individual customer accounts were not accessed or logged into, though it revoked Railway access tokens as a precaution. The company has not ruled out access to customer source code and says it expects to address that question in its final forensic report.

What customers should do

Railway recommends that customers rotate sensitive variables and keys stored on the platform before October 21, even if they have not received a direct notice. The recommendation is precautionary: Railway says it cannot yet identify every variable that may have been decrypted. Its guides for checking activity and rotating credentials cover several tools.

• Remove public network access to databases where it isn’t needed.
• Rotate sensitive variables and keys stored on Railway.
• Review GitHub organization audit logs and check installed app access.
• Check activity records for container registries, such as those described in Docker’s documentation.

Railway asks customers with questions to contact [email protected].

Infrastructure changes and open questions

Railway says it shut down potentially compromised internal tools, rotated keys twice, and replaced credentials for its storage buckets. It rebuilt infrastructure tooling from validated source and checked that the same privilege escalation paths could not be reproduced. The company also added a way to revoke Railway application permissions in bulk when suspicious activity is detected. Some response measures remain undisclosed, which limits what customers can independently assess from this report.

One notable infrastructure change was an accelerated move from third-generation isolated, multi-tenant builders to fourth-generation single-tenant environments. Railway says the rollout had been planned for the following week and was completed early in response to the incident. That shift changes how build environments are separated, but the report does not describe its performance, cost or migration implications for customers.

The key follow-up questions are whether investigators find evidence of source code access, which specific credentials were decrypted, and what additional controls Railway will describe once its review is complete. For now, customers should treat stored secrets as potentially exposed, rotate them, and check relevant service logs. Railway’s account indicates that existing workloads remained available, while build reliability and access to platform tools depended on the staged restoration.

For Railway, the practical test will be whether the rebuilt systems and new builder isolation prevent the same access paths from recurring—and whether the final report gives customers enough detail to judge their own exposure.

Source links: Railway’s October 21 disclosure.