Railway disclosed a breach on October 21, 2026, after detecting “anomalous activity” Wednesday morning in the systems that store customer environment variables. Within a day, the hosting platform had paused builds and told every user to revoke and rotate their keys, whether or not they were in the affected group. The short version if you’re checking whether this touches you: Railway said an unauthorized party “may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents,” as TechCrunch reported. Those variables hold API keys, database credentials, passwords, and private registry tokens. If you deploy on Railway, or on any platform that keeps secrets in env vars, treat your keys as exposed and rotate them, starting with whatever bills by the token.
What Railway Actually Said
Railway is a platform-as-a-service where developers build and deploy apps and AI workloads. And one report describes it as serving more than 2 million developers.
Its disclosure said an unauthorized party may have accessed encrypted environment variables. And that for some of them the attackers obtained the decrypted contents. The affected variables could contain API keys, database credentials, passwords, and private registry credentials, according to the disclosure.
Here is the part most people skimmed. Railway said its initial analysis indicated a “limited subset of users” may be affected, then told all users to revoke and rotate every key anyway. That is not a contradiction; it is the correct reading of uncertainty. When a platform cannot yet prove which variables leaked, “subset” is a hope, not a boundary. Rotate like you are in the subset.
Railway’s own response tells you how serious it considered the incident.
The company paused new builds and deployments while investigating, revoked and replaced its storage bucket credentials, reset GitHub tokens. And said it urged all of its upstream providers to invalidate affected keys. It also asked customers to check their logs for unusual activity, per Cryptopolitan. A platform does not reset its own GitHub tokens for fun.
This Was A Wave, Not A One-Off
The most important line in the disclosure was not about Railway at all.
The company said it considers this incident “part of a series of attacks recently targeting platform companies with the goal of compromising AI inference providers.” Read that twice: the platform is the delivery mechanism. And your OpenAI or Anthropic key is the product.
The framing matched events on the ground.
Days earlier, on October 16, the AI coding tool OpenCode disclosed that attackers reached a legacy system that stored customers’ OpenAI, Anthropic. And Google keys, affecting 1.4% of its Console users, according to a report. Two developer platforms hit inside a week, same class of stolen asset.
The damage was not limited to model keys either.
Blockchain investigator Taylor Monahan reportedly linked the Railway incident to approximately $371,000 in cryptocurrency drains across 19 Ethereum Virtual Machine-compatible blockchains, with more than 500 transactions across over 200 addresses, carried out by what one report characterized as a standard wallet sweeper script running on compromised private keys.
Env vars do not just hold API keys. They hold wallet private keys, database passwords, registry tokens: every secret your app needs to be trusted by something else.
My take: an AI API key is a credit card with no fraud department.
It is metered, it is resellable, and if you never set a spend cap it is effectively uncapped.
Attackers worked out that developer platforms are where those cards pool by the million. And now they are draining the pool.
The Rotation Trap: Frozen Deploys, Urgent Keys
Now the operational bind, the part that turned a security notice into a genuinely bad afternoon. Railway paused new builds and deployments during the investigation. And a report put the platform-wide pause at about a day, with Company and Pro deployments restored on October 22 while Hobby, Free.
And Trial access were still pending at that time.
Think about what that means mechanically.
Rotating a key on a platform like Railway means changing an environment variable, which means a redeploy. If deploys are frozen, you cannot swap the secret inside the running app. Your options were to leave the app running on a possibly stolen key, or take it down and wait. Every deploy platform has this trap, and almost nobody writes a runbook for it until the day it fires.
The fix is to rotate upstream first.
Revoking the old key at OpenAI, Stripe, or AWS does not require a redeploy; it kills the stolen key wherever it lives. Then you swap in the new value once deploys resume. And you take the brief outage on your schedule instead of the attacker’s. Railway said it urged its upstream providers to invalidate keys, so some of yours may already be dead. Do not count on that; verify each key yourself. That ordering, revoke at the provider and redeploy later, is the single most useful thing to take from this incident.
Your Rotation Order, Ranked By What Bleeds Fastest
Railway said the potentially exposed credentials could provide access to OpenAI, Anthropic, Grok, OpenRouter, Stripe, GitHub, AWS.
And Google Cloud, and it advised customers to examine their usage across all of them.
It too published per-service rotation guides covering PostgreSQL, MySQL, MongoDB. And Redis passwords alongside the cloud and AI providers, per the disclosure tracker.
Here is the order I would work in, ranked by how fast a stolen credential costs you money:
1. Anything that moves money directly. Stripe keys and any wallet private keys.
The reportedly $371,000 in crypto drains came from this class of secret.
2. Cloud accounts. AWS and Google Cloud keys can spin up compute that you pay for.
3. AI inference keys. OpenAI, Anthropic, Grok, OpenRouter.
Metered, resellable, and the stated target of this attack wave.
4. GitHub tokens. Slower to monetize, miserable to clean up after.
5. Database passwords. PostgreSQL, MySQL, MongoDB, Redis, in that batch of guides.
While you are in there, check usage and billing dashboards for anything anomalous; Railway explicitly asked customers to check their logs for unusual activity.
Then fix the structural problem so the next wave does not land the same way.
One key per app, so revocation does not cascade across your whole stack. Spend caps on every metered provider. A rotation cadence you actually run instead of one you intend to.
What I’m Changing
Every automation I ship carries keys for a model provider, a database, and a payment service in its environment.
That convenience is exactly what this attack wave monetizes: platforms pool millions of keys in one place. And attackers breach the pool instead of picking locks one at a time. Railway itself said this is a series aimed at AI inference providers, and OpenCode was hit days before it. There will be another disclosure.
So my checklist this week is rotate, cap, separate.
Rotate anything that ever sat in a shared platform’s env vars. Cap spend on every metered key so a theft is annoying instead of ruinous. Separate your secrets so no single host holds all of them. Run the five-step rotation order above today, then set the caps. Because two hours of work now beats explaining an inference bill you never ran up.
