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. Railway has not said how many accounts were affected, how the attacker got in, or which AI inference providers it notified, and we found no independent account of the intrusion. We will update this when it can be confirmed, and remove this note.

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.

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