Railway says attacker may have read customers' environment variables, pauses all builds and deployments

Railway, the cloud platform many small teams use to deploy apps and databases, said on Wednesday 21 October 2026 that an unauthorized third party may have accessed customers' encrypted environment variables and, for some of them, obtained the decrypted contents. Because those variables commonly hold API keys, database passwords and registry credentials, the company tells customers to roll every secret stored on the platform. It has also paused builds and deployments, and at the time of writing only Enterprise workspaces have builds back.

Key points

• Railway disclosed on 21 October 2026 that an unauthorized party "may have accessed" encrypted environment variables and, for some, decrypted contents.
• Railway says its initial analysis suggests the impact "may be limited to a subset of users", yet it advises all customers to roll all stored environment variables and private registry credentials.
• Builds and deployments were paused; according to Railway's status page, builds for Enterprise workspaces returned at 03:32 UTC on 22 October, with Pro, Hobby and Free/Trial to follow.
• Railway rotated bucket (storage) credentials and, at 04:17 UTC on 22 October, invalidated all Railway API tokens, so integrations need new ones.
• Railway has not said how many customers are affected, how the attacker got in, or when the access began.

What happened

Railway's disclosure post, titled "Security Disclosure: Wednesday October 21st", says the company detected "anomalous activity" involving systems that store customer environment variables earlier that morning. Its investigation so far indicates that an unauthorized third party may have accessed encrypted environment variables and that, for some of them, the decrypted contents were obtained. Railway lists the kinds of secret that can live in such variables: API keys, database credentials and registry credentials.

The company says its initial analysis suggests the impact may be limited to a subset of users, and that it is still confirming which accounts were affected and will email those customers directly. It also says it notified upstream providers so they could proactively revoke keys, and that it paused all deployments while it investigates. New versions of services cannot be rolled out until builds are restored.

Railway's status page gives the operational side of the day. All times below are UTC and come from the page's own entries; the page shows no year, and the entries are Railway's, not independently verified.

• 21 October, 07:24: the first entry says the company is investigating an issue. By 09:28 the entry says the dashboard, API and CLI were unavailable and builds were paused in all regions.
• 11:33: the API was back up but some features were unavailable. Through the afternoon, builds stayed paused and the support site was down, so customers could not file new support requests.
• 19:15: Railway said builds would return in stages, Enterprise first, then Pro, Hobby and Free/Trial.
• 20:19: an entry says OAuth sessions were invalidated because of impact from adjacent cache systems.
• 21:59: a security notice was published and the page said deployments remained paused, including for Enterprise. It recommends revoking all environment variables, including API keys and private registry credentials, and reviewing service logs for unusual activity.
• 22:10: all bucket credentials were being rotated. Because builds were paused, services could not redeploy to pick up new credentials. An entry at 22:45 notes that credential revocations by a Railway employee may appear in customers' audit logs, which it says is expected.
• 22 October, 01:22: guides were published, including "Check for Anomalous AWS Access" and "Check for Anomalous GCP Access", plus guides for rotating PostgreSQL, MongoDB, Redis and MySQL credentials.
• 03:32: builds for Enterprise workspaces became available.
• 04:17: all Railway API tokens were invalidated; users must create new tokens for the Public API.
• 04:39 and 04:52: services with pre-deploy commands were reported stuck at "Running pre-deploy command", and Redeploy was fixed for Enterprise. Work continued to enable builds for the other tiers.

One caution on the timeline: the status page does not label its earliest entries as a security matter. The first explicitly security-related entry is the 21:59 notice, and the blog post says only that the activity was detected "earlier this morning". How the early-morning outage relates to the intrusion is something Railway has not spelled out, so we do not claim a link beyond what it states: an "earlier issue across multiple systems" led to paused builds (19:30 entry).

Background

Railway is a platform-as-a-service: you connect a repository, it builds and runs your service, and you configure the service through environment variables, which is where most developers put secrets. Storing secrets in environment variables rather than in code is the standard advice from the twelve-factor style of app design, which also means a platform's variable store is a concentrated target. An attacker who reaches it can collect credentials for many unrelated downstream services at once: cloud accounts, databases, payment providers and AI model APIs.

Railway says it believes the incident is part of a series of recent attacks on platform companies, with the aim of compromising AI inference providers. It gives no evidence in the post for that framing, and we could not find an outside party that corroborates it, so treat it as Railway's assessment rather than an established fact. The wider pattern of the past weeks is real, though, and we have covered pieces of it: a credential-stealing build of the LiteLLM Python package, backdoored OVHcloud CLI releases and malware found in a Rank Math Pro release. Nothing published so far ties those incidents to Railway's, and we do not suggest they are connected; they show how often developer tooling and its secrets are being targeted.

How the exposure works

Encrypted at rest does not mean safe if the system that decrypts the data is reached. A platform has to decrypt variables to inject them into a running service, so an intruder with access to that path may see plaintext. Railway's wording ("may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents") suggests that the second step happened only for part of the data, but it does not say which part or how.

That is why the advice is blunt: roll everything. For a typical project this means the following, in roughly this order:

1. Credentials that reach other people's systems first: cloud provider keys (AWS, GCP), AI provider keys, payment and email provider keys. Disable the old key before creating the new one if the provider allows it, then check the provider's usage or audit logs for requests you did not make.
2. Database credentials: Railway's own guides cover PostgreSQL, MongoDB, Redis and MySQL. Rotating the password invalidates connection strings held anywhere else, so update every consumer.
3. Registry credentials for private container or package registries.
4. Third-party tokens that your app uses to call back: webhook signing secrets, OAuth client secrets, session-signing keys. Rotating a session-signing key logs users out, which is the point.
5. Railway's own tokens: Railway has already invalidated all API tokens, so any CI job or script that used one will fail until you issue a new one.

Because builds were paused, there was a practical snag: you can change a variable in the dashboard, but a running service only picks up the new value on the next deploy. Railway's own status entry at 22:10 notes this for bucket credentials. Until builds are restored for your tier, a rotated secret may not be in use by your service, and the old one stays live. The status page suggests "Deploy Latest Commit" as a workaround for Enterprise while Redeploy was being repaired.

For the AI-provider keys specifically, one community roundup we read advised xAI users to check their Usage Explorer, grouped by API key, for requests they did not make. That roundup does not report confirmed misuse, and it does not link Railway's notice, so we cite it only as an example of the kind of check to do with any provider's usage dashboard.

What it means

For Railway customers, the cost is a day of rotating secrets and a stalled deploy pipeline, which hurts most for teams that need to ship a fix or a rotated credential right now. The paused builds are the more visible harm; the real risk is any secret used before it was rotated.

For everyone else who keeps secrets in a hosting platform, the lesson is old but easy to forget. Scope keys narrowly (a key that can only call one API and one project), set spend limits on AI provider accounts, and prefer short-lived credentials where the provider supports them. A leaked key that expires in an hour is a much smaller problem than one that lives forever.

For platform providers, the incident adds to pressure to show customers how secrets are protected in use and not only at rest, and to tell them quickly and plainly when something goes wrong. Railway published a status trail with timestamps and follow-up guides within a day, which gives customers something to act on, although the underlying questions are unanswered.

What we don't know yet

• How many customers and variables are affected. Railway says "a subset" and is confirming.
• How the attacker got in, and when the access started and ended. The post gives no intrusion time.
• Whether anything beyond environment variables was taken. Railway's post says nothing either way.
• Who is behind it. Railway links the incident to a broader campaign against platform companies but names no actor and gives no evidence.
• When builds return for Pro, Hobby and Free/Trial workspaces. At the last status entry we read (04:52 UTC on 22 October) only Enterprise was restored.

Two further Railway posts dated 22 October were listed on the disclosure page, the AWS and GCP access guides; we have not reviewed their instructions in detail and you should follow Railway's own versions.

What to watch next

Watch Railway's status page and its disclosure post for the scope, for the entry point, and for the restoration of builds for lower tiers. If you are an affected customer you will be contacted by email; do not wait for that before rotating. If you use Railway, check your connected cloud and AI provider accounts for activity you do not recognise from 21 October onwards, and look at your audit log, remembering that Railway says its own staff's bucket-credential revocations will appear there.

This article was written from Railway's own disclosure and status page and two secondary write-ups that repeat Railway's account; we have not found independent confirmation of the details beyond that, and we will add a dated update when Railway publishes more.

Sources

• Railway: Security Disclosure, Wednesday October 21st (primary)
• Railway status page (incident entries, 21 and 22 October)
• LavX News: Railway discloses breach of encrypted environment variables, pauses all deployments (repeats Railway's post)
• daily.dev: Railway security incident, roll your keys and check for unexpected Grok usage (community roundup)