Illustrative image: servers in a data centre. Image: Wikimedia Commons / BalticServers.com, CC BY-SA 3.0.
TL;DR: The railway breach 100000 workspaces explained in Railway's final incident report of 10 November 2026: attackers spent about 26 hours inside the cloud platform's systems on 20–21 October, decrypted environment variables in at most 1.85% of workspaces — about 100,000 at the upper bound — and ran up roughly $740,000 in unauthorised AI charges on stolen keys. Railway says every route the attackers used is now closed and it will cover charges that providers will not refund.
Key Highlights
- Railway published its full incident report on 10 November 2026, three weeks after first disclosing the attack on 21 October.
- Attackers were inside Railway's systems for about 26 hours, from the first exploit at 07:28 UTC on 20 October until they were fully evicted at 09:24 UTC on 21 October.
- At most 1.85% of workspaces — about 100,000 — could have had environment variables decrypted. That is an upper bound, not a confirmed count.
- Linked-account tokens for 1,852 users, including GitHub OAuth tokens and bring-your-own-key agent keys, were exposed and have been reset.
- Stolen AI provider keys were used to generate about $740,000 in unauthorised charges. Railway is working with providers on refunds and will pay what providers will not.
- The attack is one of at least nine October breaches of AI developer platforms that cloud-security firm Wiz calls "Black October".
Railway breach 100000 workspaces explained: the 26-hour attack
First, what Railway is. Railway (railway.com) is a cloud platform where developers host apps, APIs, bots and databases. Customers store secrets — API keys, database passwords, tokens — as environment variables, the settings a running app reads at startup. This story has nothing to do with Indian Railways or IRCTC: no train tickets, no passenger data and no railway bookings are involved.
The attack began quietly. The attacker started creating dummy accounts on 18 October to probe the platform; those early attempts failed. Then, at 06:50 UTC on 20 October, the probing turned to Railway's build infrastructure — the shared system that turns customer code into running apps. At 07:28 UTC (12:58 IST), the attacker exploited a previously unknown vulnerability in that multi-tenant build system and partly escaped the filesystem isolation that is supposed to keep one customer's build from seeing another's files. That escape handed them a credential Railway's build servers use to talk to internal systems.
An alert on unusual API calls to a registry service paged the on-call engineer at 13:58 UTC (19:28 IST), and the incident response began. But the attacker had already used the stolen credential in a second way: Railway's build system accepted it as a trusted client of its internal Temporal task system, so the attacker could read stored histories of other builds — 353 of them, between 13:50 and 15:30 UTC — and, through a build snapshot, retrieve a copy of Railway's own internal source code. With the codebase in hand, the attacker could run AI agents across it to find more ways in, fast.
Railway halted builds at 17:03 UTC, revoked and replaced the build credential at 17:28 UTC, and re-enabled builds, believing the escalation path was contained. The attacker tried to break out of build isolation again and failed — but, unknown to Railway at the time, they already had the codebase and were probing from new angles, including endpoints that had not been used for weeks, months or even years.
The second entry point came at 03:26 UTC on 21 October (08:56 IST). Scanning the stolen code, the attacker found a wrongly configured OIDC trust binding in one of Railway's cloud environments and used it to obtain a short-lived cloud credential. From there they reached an orchestration machine, took a longer-lived credential stored on it, and used it to pull encrypted environment-variable envelopes out of a production database between 04:07 and 05:21 UTC. Database logs show the attacker's queries used regular expressions to match variable names for AI provider keys, and deliberately targeted customers with large numbers of variables. Decryption ran in two windows, 04:42–05:14 and 06:36–07:15 UTC.
At 07:14 UTC Railway disabled all active cloud credentials, shut off the key-decryption service entirely and halted builds a second time. The attacker was fully evicted at 09:24 UTC (14:54 IST) on 21 October, and Railway says they had no access to any customer data after 09:25 UTC. The company had already warned the affected AI providers at 09:25 UTC — GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google and Stripe — so keys could be revoked while Railway was still securing its own systems.
| When (UTC) | What happened |
|---|---|
| 18 Oct | Attacker creates dummy accounts and probes the platform; attempts fail. |
| 20 Oct, 07:28 | Previously unknown flaw in multi-tenant build system exploited; filesystem isolation partly escaped; build credential stolen. |
| 20 Oct, 13:50–15:30 | Attacker reads 353 stored build histories and retrieves Railway's internal source code. |
| 20 Oct, 13:58 | Alert on anomalous API calls pages the on-call engineer; incident response starts. |
| 20 Oct, 17:03 / 17:28 | Builds halted; build credential revoked and replaced; builds re-enabled. |
| 21 Oct, 03:26 | Misconfigured OIDC binding exploited; short-lived cloud credential obtained. |
| 21 Oct, 04:07–05:21 | Encrypted environment-variable envelopes pulled from the production database. |
| 21 Oct, 04:42–07:15 | Some retrieved variables decrypted using the stolen credential. |
| 21 Oct, 07:14 / 07:22 | All cloud credentials disabled; key-decryption service shut off; builds halted again. |
| 21 Oct, 09:24 | Attacker fully evicted from Railway's systems. |
| 22 Oct, 22:49 | Builds restored for all plans after infrastructure hardening. |
| 2 Nov | New signups reopened. |
What was taken — and what was not
The number in most headlines — 100,000 workspaces — needs careful handling. Railway's logs can identify which environments were exposed, but not which individual variables inside them were decrypted. So "at most 1.85% of workspaces, about 100,000" is a ceiling: the maximum that could have been affected, not a confirmed count of stolen secrets. Railway emailed the customers it rates at high risk of having credentials stolen, based on its forensics. Anything the attacker copied but did not decrypt can no longer be decrypted, because the credential they used has been disabled.
Illustrative image: a data centre corridor. Image: Wikimedia Commons / Christopher Bowns, CC BY-SA 2.0.
| What | What Railway's report says |
|---|---|
| Environment variables | Decrypted in at most 1.85% of workspaces (about 100,000) — an upper bound, not a confirmed count. |
| Linked-account tokens | BYOK agent keys and GitHub OAuth tokens for 1,852 users exposed; all reset and users notified. |
| Build histories | 353 stored build histories read, sealed variables included. |
| Unauthorised AI spend | About $740,000 estimated, on stolen AI provider keys. |
| Customer Git repositories | No evidence the attacker downloaded them. |
| Customer databases | No evidence the attacker accessed them. |
| Railway account logins | No logins to Railway accounts using stolen credentials have been seen. |
The $740,000 figure is Railway's estimate of unauthorised AI usage on the stolen keys. Railway says it is coordinating refunds with the AI providers and will cover the cost itself where a provider will not. The policies differ by vendor: AWS Bedrock and Google Gemini are refunding under their existing fraud policies; OpenAI reviews refunds case by case through a shared channel with Railway; Anthropic's costs are being covered by Railway in the interim while talks continue; and OpenRouter, which is enforcing its no-refund policy, will have all related costs covered by Railway. Customers who spot charges they did not make can report them through Railway's claims form, linked in the incident report.
Why AI keys were the target: Black October
Railway's forensic work leaves little doubt about motive. The attacker's database queries were written to match AI provider key names, and the company believes the keys were passed to "distributed transfer stations" for use in distillation — harvesting model outputs to train other models. The unauthorised use seen since ranges from coding-agent requests to AI training pipelines and checks of training tasks and their scoring systems, consistent with stolen credentials being resold through services that relay access to AI providers.
The attack itself was, in Railway's words, "a contest of agent speed": the attacker used AI models with their safeguards removed, plus an agent harness similar to ARTEX, to probe many routes in parallel while Railway's engineers hardened them in parallel. Railway's report also notes that Fireworks AI, OpenCode and Warp reported signs of similar "agent swarm" attacks. Our Fireworks AI data breach explainer covers the second incident that platform disclosed on 24 October.
Wiz, the cloud-security company, counts at least nine AI developer platforms that disclosed incidents in October 2026 — Fireworks AI on 6 October, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode and Northflank on 30 October — and calls the month "Black October". Wiz is careful about what that label means: it found no single vulnerability or software dependency linking the nine, and no single attacker has been proven behind all of them. What they share is a target — the stored environment variables where customers keep the keys that unlock paid AI models — and a business model: steal the key, spend someone else's money, or resell the access. Wiz traced two stolen enterprise keys into reseller pools that made about 2.5 million Amazon Bedrock calls and ran up more than $100,000 at list price.
What it means for Indian developers
Railway is popular with Indian indie developers, students and early-stage startups: it is one of the easiest places to put a side project, a Telegram or Discord bot, or an AI demo online without managing a server. That is exactly the audience this breach hits. If you deployed anything on Railway before 21 October and stored an OpenAI, Anthropic, Google or OpenRouter key in its Variables tab, assume that key may have been seen — even if you received no email from Railway, because only customers rated high-risk were emailed directly, while everyone who signed up before 21 October was told to rotate.
The pattern is bigger than one platform. In India, CERT-In warned in its 4 November "Crafty Falcon" advisory that AI-driven tools are now being used to attack financial firms at machine speed — our CERT-In Crafty Falcon explainer has the details — and the Railway report shows the same shift on the infrastructure side: the attacker was not a person typing commands, but agents working through a codebase at speed. For Indian teams building AI features, the lesson is the same in both cases: keys that can spend money need the same care as passwords, including spending limits and usage alerts at the provider, not just secrecy.
One clarification worth making for Indian readers: this Railway is the San Francisco cloud company at railway.com. It is not Indian Railways and has no connection to IRCTC, train tickets or passenger data.
Should you care? What to do now
Verdict: ✅ Act if you used Railway; learn from it if you did not. If you had anything on Railway before 21 October, rotate every secret stored there, starting with AI provider keys. Railway has already revoked its own API tokens and every user session, reset the 1,852 exposed linked-account tokens, and rebuilt its build and CI systems — but a key you created is only dead when you revoke it at the provider. If you never used Railway, the takeaway still applies to any platform holding your keys: rotate on a breach, and set billing alerts before you need them.
Railway's own advice, first published on 21 October and unchanged by the final report, is to revoke and replace all environment variables stored on the platform before 21 October, including API keys and private registry credentials. Do it in this order:
| Priority | What to rotate | Where |
|---|---|---|
| First | AI provider keys (OpenAI, Anthropic, Google Gemini, OpenRouter, Grok) | Each provider's console — create the new key, update Railway, then delete the old one. |
| First | GitHub OAuth tokens, personal access tokens and linked accounts | GitHub settings — check authorised apps, SSH keys and the audit log too. |
| Next | Database passwords (PostgreSQL, MySQL, MongoDB, Redis) | Your database provider's console. |
| Next | Cloud and payment keys (AWS, GCP, Stripe) | Each provider's console; check billing for October charges you did not make. |
| Then | Everything else in the Variables tab — session secrets, webhook signing secrets, email and SMS keys | Railway dashboard, then redeploy so the running service picks the new values up. |
Two practical notes. First, Railway's containers only read variables at startup, so rotate and then redeploy — changing a value without redeploying leaves the old one live. Second, check each provider's usage and billing logs for October: stolen keys were used for coding agents and training pipelines, so unexpected model calls are the fingerprint. This is also the week to patch everything else: CISA has set a 12 November deadline on four actively exploited flaws, covered in our CISA KEV November 2026 explainer.
FAQs
What happened in the Railway breach?
Attackers exploited an unknown flaw in Railway's multi-tenant build system on 20 October 2026, escaped filesystem isolation, stole a build credential, read Railway's own source code, then used a misconfigured cloud trust setting to reach and decrypt customer environment variables. They were evicted about 26 hours later, on 21 October. Railway published its full incident report on 10 November 2026.
Were my API keys stolen in the Railway breach?
Possibly, if you stored them on Railway before 21 October. Railway says at most 1.85% of workspaces — about 100,000 — could have had variables decrypted, but that is an upper bound, not a confirmed count, and its logs cannot say which individual variables were taken. Railway emailed customers it rates high-risk; everyone else was still told to rotate all secrets.
Is Railway safe to use now?
Railway says every vector the attackers used has been fixed. Builds now run on dedicated ephemeral virtual machines instead of shared multi-tenant ones, the CI system was rebuilt with two-factor approval and biometrics in critical areas, and secret storage now has central audit logging. New signups, paused on 22 October, reopened on 2 November. The platform is operating normally.
Will I get my money back for fraudulent AI charges?
Railway is coordinating refunds with each AI provider and says it will cover charges from its own funds where a provider will not. AWS Bedrock and Google Gemini are refunding under fraud policies, OpenAI reviews cases individually, and Railway is covering Anthropic and OpenRouter costs. Report charges you did not make through the claims form linked in Railway's incident report.
Takeaway
The Railway breach is the clearest case yet of a new kind of theft: attackers no longer break in to steal data, they break in to steal the keys that buy AI. At most 100,000 workspaces were in scope, about $740,000 was spent on other people's keys, and the fix for users is unglamorous but complete — rotate every secret, check every bill, and never let a key that can spend money sit unmonitored.
If you host anything on Railway, open your Variables tab today and rotate the AI keys first — then read our Fireworks AI breach explainer to see how the same key-hunting pattern hit a second platform in the same month.
Sources
- Railway — Incident Report: October 21st Security Attack (10 November 2026)
- BleepingComputer — Railway breach leads to $740,000 in fraudulent AI charges (10 November 2026)
- The Hacker News — Railway Says Stolen Customer AI Keys Led to $740,000 in Estimated Unauthorized Usage Charges (11 November 2026)
- Wiz — "Black October" for AI Developer Platforms (30 October 2026)
- Dev.to — Railway's Breach Cost $740,000 in Fraudulent AI Charges — and Up to 100,000 Workspaces May Have Leaked Secrets (11 November 2026)
Comments
Post a Comment