Railway Security Breach: What Happened and What to Do Now

Railway, the application-deployment platform used by thousands of developers to host backends, databases and side projects, disclosed a security incident on October 21, 2026, after detecting unauthorized access to systems that store customer environment variables. The company paused builds and deployments platform-wide, invalidated OAuth sessions and, by October 22, invalidated every Railway API token in existence. If you run anything on Railway, the company's own guidance is blunt: rotate your environment variables, your database credentials and your API keys now, and check for unexpected activity on any service you connected a Railway secret to.

What happened to Railway, in plain terms

Railway's own account of events, published on its blog as a security disclosure, says the company detected anomalous activity affecting the systems that store customer environment variables. The post states that the investigation "indicates an unauthorized third party may have accessed encrypted environment variables" and that, for some of those variables, the attacker also obtained the decrypted contents. Because environment variables are where developers routinely store API keys, database connection strings and registry credentials, that second detail is the one driving every recommendation that followed.

Railway has not described the technical root cause of how access was obtained. The closest it comes is a status-page line, posted at 20:19 UTC on October 21, attributing the OAuth session invalidation to "impact from adjacent cache systems" — a phrase Railway has not expanded on. The company has also said it believes this incident sits inside a broader series of attacks targeting platform companies with the specific goal of compromising AI inference provider credentials, and that it has already notified those upstream AI providers so they could revoke exposed keys on their end.

The incident timeline, hour by hour

Railway's status page has logged the incident, titled "Railway Platform Outage," in close to real time. Below is the sequence as Railway itself has posted it, in UTC.

Railway's incident entry was still marked "Identified" as of the October 22 update, meaning the company has not yet closed it out with a resolved/postmortem status.

The security disclosure Railway sent customers

At 21:59 UTC on October 21, Railway published a post titled "Security Disclosure: Wednesday October 21st," written by Jacob Cooper. Its core instruction, quoted directly: "We strongly recommend that you revoke all environment variables stored in Railway, including API keys and private registry credentials." The post also tells customers to review their service logs for unusual activity, and says Railway will contact confirmed affected accounts directly by email once it has finished identifying them.

Railway is careful to say that "the impact may be limited to a subset of users," but it is not limiting the rotation advice to any subset — the recommendation applies platform-wide, to every account, regardless of plan tier. If you have not received a direct email from Railway, that is not confirmation you were unaffected; it only means Railway's account-by-account review hadn't reached you yet as of publication.

Why your Railway login and API tokens stopped working

Two separate invalidations hit Railway users in the 24 hours after the notice. The first, at 20:19 UTC on October 21, force-logged-out users whose OAuth sessions Railway invalidated because of the "adjacent cache systems" impact mentioned above — you'd have simply been asked to sign back in. The second was bigger: at 04:17 UTC on October 22, Railway invalidated every API token on the platform "in line with the security disclosure," which the status page says breaks existing integrations until replacement tokens are issued. If you have CI pipelines, CLI scripts, or third-party tools authenticating to Railway's public API, assume those calls are now failing and need new tokens generated from your account settings.

What to rotate right now

Railway published a dedicated set of recommendation guides at 01:22 UTC on October 22 — separate short posts for each credential type and each third-party provider you should check. The table below rolls them into a single checklist in the order Railway's own guidance implies.

If you'd rather follow a zero-downtime method instead of rotating everything in one risky swap, Railway's own credential-rotation documentation lays out the overlap approach: issue the new credential first, move traffic to it behind a healthcheck, confirm it works, and only then revoke the old one. The one rule the guide insists on is that a running service should never be left holding a credential that's already been revoked.

Checking the services your Railway secrets touch

Because Railway's disclosure centers on environment variables rather than a single credential type, the practical risk extends to whatever those variables unlocked. Railway's own follow-up posts walk through checking GitHub access logs for anything your team didn't authorize, and reviewing Stripe for unexpected charges, API calls, or new restricted keys. Separate guides cover AWS and GCP access review, and four more cover each AI inference provider by name. None of these guides are optional add-ons — Railway is treating "check the provider" as equally important to "rotate the Railway-side credential," because a leaked key is only neutralized once it's revoked at the provider that issued it, not just removed from Railway's dashboard.

This is also a useful moment to double-check how the rest of your infrastructure authenticates. If you're evaluating ways to reduce how many long-lived secrets sit in a deploy platform's variable store at all, it's worth reading how developers compare Tailscale against WireGuard for locking down access between services, since fewer plaintext credentials in transit is generally fewer things to rotate during an incident like this one.

Where build restoration stands right now

Railway paused all builds and deployments platform-wide at 09:28 UTC on October 21, and announced a staged restoration plan at 19:15 UTC that same day: Enterprise workspaces first, then Pro, then Hobby, then Free and Trial. Enterprise builds came back at 03:32 UTC on October 22; Pro joined at 06:29 UTC. As of the most recent status update at 14:50 UTC on October 22, Pro and Enterprise deployments are running at close to normal speed, while Hobby, Free and Trial accounts were still waiting for builds to be re-enabled. If you're on a Hobby or Free plan and your builds are still queued or unavailable, that matches Railway's own stated rollout order — it is not a separate problem on your end.

Along the way, Railway also had to fix secondary issues created by its own remediation: a stuck "Running pre-deploy command" state (04:39–04:52 UTC) and a deployment queue backlog (07:11–13:53 UTC) that Railway asked customers not to make worse by repeatedly re-triggering the same deployment.

Has Railway said what caused this?

No — not in the sense of a technical root-cause writeup. Railway's public statements describe effects (anomalous activity on systems storing environment variables, impact from "adjacent cache systems," builds paused across the platform) rather than a named vulnerability, misconfiguration, or intrusion vector. The company has also stopped short of naming an attacker or attributing the incident to a specific group; the furthest it has gone is characterizing the event as likely part of a wider pattern of attacks against platform companies aimed at harvesting AI inference provider credentials. Railway's incident status was still listed as "Identified" rather than "Resolved" as of this writing, and no postmortem has been published yet. If and when Railway publishes a fuller technical accounting, it will appear on the same status page incident log and on its blog.

Who's affected, and what if you didn't get an email

Railway's notice says the impact "may be limited to a subset of users," but it applies the rotation guidance to everyone regardless of plan. The company says it will reach out directly, by email, to accounts it confirms were affected — but that outreach is ongoing, not instantaneous, so the absence of an email on October 22 doesn't mean you're in the clear. Given that Railway itself is telling every customer to rotate credentials as a precaution, the practical advice is the same whether or not you've been personally contacted: treat every secret you had stored in Railway as potentially exposed until you've rotated it. Developers who've been through a vendor-side credential exposure before will recognize the shape of this response — it closely mirrors how other infrastructure vendors have handled similar incidents, such as the pattern described in our coverage of the ConnectWise cloud backup breach.

Hardening your setup once things stabilize

Once builds are fully restored on your plan and you've worked through the rotation checklist above, it's worth tightening a few habits that make the next incident less painful. Scope tokens narrowly rather than using broad, account-wide keys wherever a provider supports it; use reference variables in Railway so a single credential update propagates to every consuming service instead of needing to be pasted in multiple places; and keep an eye on supply-chain style exposure more generally — the same instinct that prompts you to rotate a leaked database password is the one worth applying after incidents like the npm trusted-publishing flaw, where a dependency pipeline rather than a cloud dashboard was the point of exposure. Credential hygiene problems tend to rhyme across platforms even when the root cause differs.

What's next

Three things are still open as of October 22: Railway has not re-enabled builds for Hobby, Free and Trial accounts; Railway has not published a technical root-cause explanation or formally closed the incident; and Railway's account-by-account email notifications to confirmed affected customers are still going out. Expect further status-page updates as each of those resolves, and watch blog.railway.com for either a closing postmortem or additional recommendation guides if new systems turn out to be in scope. Until Railway marks the incident resolved, the safest working assumption for any team running production workloads on the platform is that rotation isn't a one-time task finished the moment you changed your database password — it's worth re-checking provider-side usage logs (AI inference spend, Stripe activity, GitHub access, AWS/GCP activity) for several more days, since anomalous usage from an already-leaked key can take time to show up in billing or audit data.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage