Breaches

Railway breach exposes customer secrets: rotate every key now

Railway says an intruder read customer environment variables, some decrypted. UK teams should rotate every stored key and check for misuse now.

Padlock graphic with the headline Railway breach puts customer secrets at risk

Railway, the cloud platform that many small teams use to ship web apps, says an intruder reached the systems holding its customers’ environment variables and, in some cases, read the decrypted secrets. Every Railway user has been told to rotate every key, and UK teams that host there should treat their stored credentials as exposed until they know otherwise.

What happened

On 21 October 2026, Railway published a security disclosure. It said it had detected anomalous activity that morning involving the systems that store customer environment variables. Its investigation so far suggests an unauthorised third party may have accessed those variables in encrypted form, and for some of them obtained the plaintext. On a platform like this, those variables typically hold database connection strings, cloud access keys, payment secrets, AI API keys and registry logins.

Railway believes only some users were affected but has not given a number. Its advice applies to everyone: roll every environment variable stored on the platform, roll any private registry credentials, and check the logs of the connected services for unusual activity. In TechCrunch’s words, the company wants “all users” to revoke and rotate.

The disruption was serious. Its status page shows builds and deployments paused in every region from the morning of 21 October, with the dashboard, API and support forum also hit. Railway rotated all storage bucket credentials, invalidated every existing API and project token, and signed some users out as it invalidated OAuth sessions. Builds returned in stages, Enterprise first and Free and Trial last, late on 22 October. New sign-ups remain paused.

In the early hours of 23 October (UK time), Railway said it was still emailing impacted customers and could not say when that would be finished. It plans to publish a preliminary incident report around midday US Eastern time on 23 October. That report had not appeared at the time of writing, so root cause, entry point and scale remain unknown.

The technical picture

The most significant line in Railway’s disclosure is its view of motive. It believes the intrusion is part of a series of recent attacks on platform companies, aimed ultimately at compromising AI inference providers, and it says it has asked those upstream providers to revoke keys proactively.

The pattern fits other disclosures from the past few weeks. Fireworks AI reported on 9 October that internal credentials had been misused to read environment variables used in customer evaluation jobs. Zeabur, another deployment platform, published a detailed preliminary report on 19 October. In it, Zeabur says long-lived admin credentials stored in plaintext allowed an attacker to read its platform database, which held more than three million environment variable records. TechCrunch also links Railway’s incident to OpenCode, which said attackers took API keys and other secrets from more than one per cent of its users. No single actor has been publicly linked to all of them, so treat this as a shared pattern, not a proven campaign.

According to security researcher Taylor Monahan, cited by The Hacker News, crypto wallets with private keys held in Railway were emptied, the first theft landing at least two hours before the public disclosure. Railway has not confirmed this.

What makes this class of breach so damaging is that encryption at rest does little if the attacker reaches the component that decrypts values for running workloads. Somewhere in the chain, secrets must exist in the clear for your containers to use them.

Timeline of the Railway security incident from detection on 21 October to the promised preliminary report on 23 October 2026

Why it matters for UK organisations

Railway is US-based, but its customers are global. The status page lists an EU West build region alongside US and Asia regions, and the platform is popular with start-ups, agencies and in-house product teams across the UK. Many will have wired Railway-hosted apps to customer databases, Stripe, AWS or Google Cloud, and AI provider keys with generous spending limits.

For UK controllers, the data protection question cannot wait for Railway’s report. If a leaked credential gave access to a database holding personal data, that may be a personal data breach under UK GDPR. If it is likely to pose a risk to individuals, the controller has 72 hours from becoming aware to tell the ICO. Expect the ICO to want a documented assessment of what the credentials could reach, even if you decide not to report. Hosting with a third party does not shift that duty.

The incident is also a timely example for the supply chain provisions expected under the Cyber Security and Resilience Bill. A single upstream compromise turns into thousands of downstream credential exposures, and most affected firms will have no contract or log that tells them exactly what was taken.

Expert view

When we test cloud-native estates, environment variables are one of the first places we look once we have any foothold. They are treated as configuration, not secrets, and the same key often appears in staging, production and CI. In my experience, a secrets rotation that sounds like an afternoon’s work takes days. Nobody knows everywhere each key is used, and few small teams have practised rotating a database password without breaking production.

The bigger lesson is about blast radius. Long-lived static keys with broad permissions are what make a platform breach catastrophic rather than merely inconvenient. Where providers support short-lived, scoped credentials or workload identity federation, use them. Where they do not, keep spending caps and IP restrictions tight so a stolen key is worth less.

Finally, treat the disclosure timeline with care. If the wallet thefts Monahan describes began before Railway went public, attackers may already have used some secrets. Rotation stops future abuse. It does not undo what happened before it.

What to do now

  1. Inventory first. Export the list of variable names in every Railway project and environment, and map each one to the system it unlocks.
  2. Revoke at the source, then replace. Starting with cloud, database and payment secrets, rotate keys with the issuing provider (cloud, payment, AI, database, registry) so the old values stop working, then update Railway and redeploy. Deleting a variable from Railway does not invalidate it.
  3. Hunt for misuse. Review AWS CloudTrail, Google Cloud audit logs, GitHub audit logs, Stripe events and AI provider usage from 21 October onwards, and earlier if you can. Railway has published per-service guides covering these checks.
  4. Replace Railway API tokens. Existing tokens were invalidated, so any CI integration will need a new, minimally scoped token.
  5. Assess UK GDPR duties. Decide and document whether exposed credentials reached personal data, and report to the ICO within 72 hours where the risk test is met.
  6. Harden for next time. Under Cyber Essentials’ secure configuration and user access control themes, move towards short-lived credentials, least-privilege keys and a central secrets manager.

Bottom line

Railway has been open about the disruption, but entry point, scope and timing await its preliminary report. Do not wait for it. If your secrets lived on Railway, assume they are known to someone else, rotate them at the source, check for misuse and record your decisions.

Sources

Related Posts