Railway says an attacker reached customer secrets; rotate them all

Railway says an attacker reached customer secrets; rotate them all

21 October 2026: Railway, the application hosting platform, says an unauthorised party may have accessed the encrypted environment variables its customers store with it and, for some of them, obtained the decrypted contents. Because those variables commonly hold API keys and database and registry credentials, Railway is telling every user, not only those it later confirms as affected, to replace all of them and check the services they unlock for misuse.

Not yet independently verified. The figures and timeline are Railway's own. Its full incident report of 10 November describes how the attacker got in, but the forensic investigation is still running, the $740,000 of fraudulent spend is Railway's estimate and refunds are not complete. We will update this when it can be confirmed, and remove this note.

Update, 11 November 2026: Railway published its full incident report on 10 November. It says that at 07:28 UTC on 20 October an unknown vulnerability in its multi-tenant build infrastructure let the attacker partly escape filesystem isolation and read a build credential, which Railway's internal Temporal instance accepted as a trusted client. The attacker then read the stored histories of 353 builds, including sealed variables, and a copy of internal source code, and later used a misconfigured trust relationship to decrypt per-environment keys between 04:42 and 07:14 UTC on 21 October. Railway says it evicted the attacker at 09:24 UTC on 21 October, invalidated all user sessions and tokens that evening, and restored builds for all plans by 22:49 UTC on 22 October. Decrypted variables affected at most 1.85% of workspaces, about 100,000, which Railway calls an upper bound, and linked-account tokens of 1,852 users (their own AI provider keys and GitHub OAuth tokens) were decrypted and have all been reset. Railway believes the target was AI provider credentials and puts unauthorised token spend at about $740,000; it says AWS Bedrock and Google Gemini are refunding fraudulent use, OpenAI and SpaceXSI are deciding case by case, and Railway is covering the cost of breached Anthropic and OpenRouter keys itself while talks continue. It has filed a complaint with the FBI's IC3 and engaged a forensics firm.

What Railway has disclosed

The disclosure, posted on 21 October by Jacob Cooper, says Railway detected anomalous activity that morning in systems that store customer environment variables. Its initial analysis suggests the impact may be limited to a subset of users, and it will email the customers it confirms as affected. Railway believes the intrusion is part of a series of attacks on platform companies aimed at compromising AI inference providers, and says it has asked those upstream providers to revoke keys proactively. It has not named them, and it has not described how the attacker gained access.

All deployments were paused while Railway investigated. By the morning of 22 October its status page showed builds restored for Pro and Enterprise workspaces, with Hobby, then Free and Trial plans to follow, and many deployments still queued with longer waits and higher build failure rates than usual.

Rotating keys while deploys are queued

The awkward part for customers is sequencing. A new secret only reaches a Railway service through a redeploy, and redeploys were paused or slow. Revoking a key at its provider before the replacement is live takes the service down; leaving it active keeps a possibly stolen credential usable. Railway's two follow-up guides, published on 22 October, deal with this for the two most common cloud credentials:

• For AWS access keys: create a second key, deactivate the exposed one rather than deleting it, update the variables and redeploy, then search CloudTrail event history for the old key in every region, looking for calls such as RunInstances, CreateUser, CreateAccessKey and PutBucketPolicy and for source addresses outside Railway's egress ranges.
• For Google Cloud service account keys: disable the key with the gcloud CLI, since the console cannot, or disable the whole service account if access must stop at once, because tokens already issued stay valid for up to an hour; then review Cloud Audit Logs and remove unfamiliar IAM roles.

The same logic applies to payment, email, model provider and database credentials: issue the new secret first where the provider allows two at once, cut over, then revoke, and read the provider's own usage logs for the exposure window rather than relying on Railway's.

Why AI keys were the target

Railway links the intrusion to attackers after AI inference providers, and model provider keys are the credentials it has asked upstream to revoke. Teams that kept those keys in platform environment variables should look first at spend dashboards and usage logs with their AI providers, where misuse shows up quickly as unexplained token volume. Our password management software category lists 15 products, one place to look for a secrets store that sits outside the hosting platform.

Update, 24 October 2026: Railway's preliminary report, published on 22 October, says at most 1.85% of all workspaces, about 100,000, had some environment variables potentially compromised. Because it cannot tell which variables were decrypted, it is also contacting a larger group of customers it judges at high risk of being targeted. The report does not identify how the attacker first got in.

Sources

• Railway: Security Disclosure, Wednesday October 21st, 21 October 2026
• Railway: Security Disclosure Recommendation, Check for Anomalous AWS Access, 22 October 2026
• Railway: Security Disclosure Recommendation, Check for Anomalous GCP Access, 22 October 2026
• Railway status page, platform outage updates (read 2026-10-22), 22 October 2026
• Railway: Preliminary report on the October security incident, 22 October 2026
• The Hacker News: report on the Railway incident, October 2026
• Railway: Incident report, October 21st security attack, 10 November 2026