Railway's Breach Cost $740,000 in Fraudulent AI Charges — and Up to 100,000 Workspaces May Have Leaked Secrets
Railway, the hosting platform thousands of developers use to deploy apps and run AI workloads, has published its final incident report on the October breach — and the numbers are worse than the first disclosures suggested. Attackers stole decrypted environment variables from up to 100,000 workspaces, ran up roughly $740,000 in fraudulent AI charges on stolen keys, and read the history of 353 builds, secrets included.
This article is built from Railway's final incident report (published November 10, 2026), BleepingComputer's report the same day, and Wiz's analysis — checked November 11, 2026. Where a claim is Railway's or a reporter's, I'll say so, because in a breach story, who said what matters as much as what happened.
Verdict: If you had anything sensitive in Railway before October 21, treat it as compromised until you have replaced it. Rotate every variable, revoke every key at the provider, and check your AI billing — reporting a charge does not revoke the key that made it. Railway says it will eat the $740,000 if providers don't refund it, and that no account was logged into with stolen credentials. That is genuinely good news. The bad news is the scale: this was not a narrow incident, and it was not alone.
What happened — the 26-hour fight
The timeline, as Railway tells it in its final report, is short and brutal.
The attack began on October 20 at 07:28 UTC. The attacker exploited an unknown flaw in Railway's build infrastructure to break filesystem isolation — the separation that is supposed to keep one customer's build from seeing another customer's files — and pulled credentials out of the inside. From there, they moved through the environment.
It took until October 21 at 09:24 UTC — about 26 hours — before the attacker was fully evicted. Twenty-six hours is a long time to be fighting inside your own infrastructure, and Railway's report does not hide that. If you are a Railway user, that window is the one that matters: anything that was live in Railway's build system during those hours was in the blast radius.
Railway published its final incident report on November 10, 2026, and BleepingComputer reported it the same day. The final report replaces the earlier, partial picture — and in several places it is worse.
What was taken
Here is the damage, as Railway's final report states it:
Environment variables — up to 100,000 workspaces. Railway says decrypted environment variables could have been taken from a maximum of 1.85% of workspaces — roughly 100,000, as an upper bound. Read that number carefully: it is a ceiling, not a confirmed count. Railway has not confirmed how many workspaces were actually hit, and I am not going to pretend the upper bound is the real number. But an upper bound of 100,000 is not a rounding error either. If your secrets were in Railway before October 21, the honest position is that you do not know from public information whether they were taken — so act as if they were.
Linked-account tokens — 1,852 users. GitHub OAuth tokens and bring-your-own-key (BYOK) agent keys belonging to 1,852 users were exposed. Railway says all of them have been reset. That is the right response, but if you were one of those 1,852, check that the reset actually landed — and rotate anything downstream that those tokens touched.
Build history — 353 builds. The history of 353 builds was read, secrets included, along with Railway's own internal source code. Your build history is a record of what you deployed and how; the secrets inside it are the part that matters. If any of your builds were among the 353, rotate everything that build ever carried.
Fraudulent AI usage — about $740,000. Stolen keys were used to run roughly $740,000 of unauthorised AI usage. Railway's position has flipped since October 26: where it once said it would not cover the charges, it now says it will absorb the cost itself if providers do not refund it. That is a real change, and it matters to anyone staring at an invoice they did not run up. But money is only half the story — the keys were also the attacker's product.
What was not hit, according to Railway: the customer database was not accessed, and Railway says it has seen no account logins using the stolen credentials. That is genuinely reassuring, as far as it goes. It does not undo the exposure of the secrets themselves.
The motive: AI credentials were the target
The attacker was not rummaging at random. According to the reporting, they specifically hunted for AI provider credentials — the keys that unlock paid inference and training — apparently to resell them or to distil models with them. Some queries also swept up cloud, database and payment credentials that happened to be in the same variables.
This is the same pattern behind the wave of October breaches. Wiz has tracked a series of thefts of AI credentials across developer platforms between October 6 and 23 — OpenCode, Warp and Fireworks AI among them — and Fireworks' own follow-up bulletin on November 9, 2026 admitted attackers had reached customer datasets and model weights. I covered that one yesterday; if you use Fireworks, that article still applies. Railway is the latest and, by the $740,000 figure, the most expensive name in the wave so far.
The logic is simple and it is not going away: AI provider keys are money. A stolen key can be sold, or used to run workloads someone else pays for, or used to train a model on someone else's bill. Any platform that concentrates those keys — a host, an inference vendor, an agent platform — is now a high-value target, and the attackers know it.
What to do now — if you use Railway
Do these in order. None of them requires waiting for Railway to tell you whether you were affected — assume the worst until you have evidence otherwise.
- Revoke or replace every sensitive variable you had in Railway before October 21. Not just the ones you remember — all of them. Env vars are the core of this breach. If a variable was in Railway before the eviction on October 21, treat it as known to the attacker.
- Rotate the keys at the provider, not just in Railway. This is the step people skip. Replacing a variable in Railway does nothing if the old key is still valid at OpenAI, Anthropic, Google or wherever it points. Go to each provider and revoke the old key, then issue a new one. Reporting a fraudulent charge does not revoke the key that made it — that is a separate step, and it is yours.
- Check your AI billing, line by line. Look for usage spikes, unfamiliar models, regions you never use, and charges after October 20 that do not match your own logs. $740,000 of fraudulent usage went through stolen keys; your invoice is often the first place it shows up. If you find charges you did not make, report them — and then do step 2 anyway.
- Check the tokens Railway already reset. If you were among the 1,852 users whose linked-account tokens were exposed, confirm the reset landed and re-link anything that broke. Then check what those tokens could reach — a GitHub OAuth token is a door, not just a string.
- Audit what your builds carried. If any of your builds were among the 353 whose history was read, list every secret that build ever carried — including the ones you rotated since, because the history is a record, not a snapshot. Old secrets in build history are still secrets.
- Watch for downstream use. If a stolen key was an AI provider key, think about what an attacker could do with it beyond running up a bill — including distilling a model or impersonating your service. And if any cloud, database or payment credential was in the same variables, rotate those too; the reporting says some queries swept those up as well.
What to do now — if you use any hosting or AI platform
Railway is the story today, but the lesson is general, and October proved it:
- Scope every secret to one place, one purpose. A key that is valid in Railway and also in your CI, your laptop and your staging setup is a key that one breach compromises everywhere. One secret, one home.
- Keep secrets out of build history. Builds are supposed to be reproducible; they are not supposed to be a vault. If your build logs or history can show a secret, assume they will.
- Monitor your AI spend like it is a bank account. Set billing alerts at levels that would catch a stranger running workloads on your tab. Most providers let you do this; most teams never turn it on.
- Have an exit plan before you need one. If your deploy pipeline is welded to one host, a breach there is a crisis everywhere. An abstraction over your deploy and inference calls is not premature engineering — it is insurance, and this month showed why.
The bottom line
Railway's final incident report, published November 10, 2026, says an attacker broke build filesystem isolation on October 20, was evicted about 26 hours later, and in that window could have taken decrypted environment variables from up to 100,000 workspaces, exposed linked-account tokens for 1,852 users, read the history of 353 builds, and run up roughly $740,000 in fraudulent AI charges on stolen keys. Railway will cover the charges if providers do not refund them, the customer database was not accessed, and no account logins with stolen credentials have been seen. It is one incident in a wave that also hit OpenCode, Warp and Fireworks AI in October.
If you use Railway, revoke and replace every sensitive variable from before October 21, rotate the keys at the provider, and check your billing — today, not when a notification arrives. If you use any platform that holds your secrets, take the same lesson: scope your keys, keep them out of build history, and watch your spend like a bank account. The platforms have become targets because they hold exactly what attackers want. Act like it.
Were you running anything on Railway before October 21 — and have you rotated everything yet?
Sources: Railway final incident report, November 10, 2026; BleepingComputer, "Railway breach leads to $740,000 in fraudulent AI charges," November 10, 2026; Wiz analysis; ExplainX summary of the Railway/OpenRouter attacks. The 100,000 figure is Railway's stated upper bound (1.85% of workspaces), not a confirmed count, and is presented as such. No hands-on testing was performed for this article. This breaking article is not the daily buyer-intent post, and it contains no affiliate links.
