How a build job became a key vault
The chain matters because no single step looks like a breach of a secrets store. The attacker started in the build system, where several customers' builds shared one host under filesystem isolation. Escaping that isolation, partially, yielded a credential meant for pushing finished images. That credential turned out to be trusted well beyond its job: Railway's internal Temporal cluster accepted it, and Temporal's stored build histories contained the variables and secrets passed to other people's builds, plus repository snapshots. One snapshot was Railway's own monorepo. Railway says that copy is what let the attacker probe endpoints unused for months and find the second door, a wrongly defined OIDC binding in a cloud environment, at 03:26 UTC the next morning.
From there the path ran through internal credentials to a machine whose disk held a credential able to decrypt customer variables. Railway reports decryption activity during two windows on October 21: 04:42–05:14 UTC and 06:36–07:15 UTC, with credentials disabled at 07:14 UTC. Railway observed queries prioritizing AI-provider credentials and assesses that resale for distillation was the objective.
Railway's response was extensive: builds halted twice, every user session and token invalidated, and revocation requests sent to providers from 09:25 UTC — Railway says it supplied key hashes when requesting revocations — alongside an accelerated move to the single-tenant build system it had planned to roll out the following week. Running deployments stayed up throughout; it was new builds that stopped, which left some customers unable to redeploy with rotated credentials until builds returned on October 22.
Two numbers, read two different ways
The exposure figure and the cost figure look like the same kind of number. They are not.
The 100,000 is an upper bound Railway's available logs do not resolve into an exact affected-workspace count. Its logs show which environments were within reach, not which variables inside them were decrypted, so the honest statement is "at most 1.85%," and Railway, to its credit, keeps saying it that way, including in the preliminary report three weeks earlier. The separate, exact measurement in the report is the access itself: stored histories of 353 builds read, sealed variables included. Any version of this story that reports 100,000 workspaces breached as a count has upgraded an upper bound into a fact.
The $740,000 runs the other way. Railway estimates approximately $740,000 in unauthorized spending but provides no calculation, provider breakdown or measurement period in the report. It is the report's only cost figure, and it should be read as what it is: the platform's own estimate, published without its workings.
Who pays has changed
The most concrete change in the final report is not technical. On October 26, Railway published the position that it was unable to refund spend performed with compromised keys and sent customers to the providers. The November 10 report commits Railway to covering token-related losses that providers do not cover: refunds where providers pay, Railway's own balances where they will not, including OpenRouter, which Railway says is holding to a no-refund policy in its terms, and Anthropic, where Railway says discussions are still open and it is covering costs in the interim. Those provider statuses are Railway's account, not independent confirmation from the providers.
That commitment has soft edges worth noting. It runs through a report form, with no cap or deadline stated, and no statement of whether a customer must pay a disputed charge while a claim is reviewed. It also does nothing by itself about the keys. A refund settles a bill; it does not revoke a credential. Potentially exposed credentials should be revoked and replaced in accordance with the incident guidance. That prevents continued use of those credentials; it does not reverse prior access or settle resulting charges.
Sources
- [1] Railway, "Incident Report: October 21st Security Attack", November 10, 2026 (last updated 18:02 UTC) (timeline, Temporal build-history access and monorepo retrieval, OIDC binding, regex queries prioritizing AI keys, two decryption windows on October 21 — 04:42–05:14 UTC and 06:36–07:15 UTC — with credential disabling at 07:14 UTC, 1.85% / ~100,000 upper bound with the environments-not-variables caveat, 353 build histories, 1,852 users' tokens reset, ~$740,000 estimate, provider-by-provider refund account and backstop commitment, dedicated ephemeral VM builds, FBI IC3 complaint, and the note that Wiz's Black October research does not independently attribute this incident; read first-hand by the ALFW desk)Read source
- [2] Railway, "Preliminary Report: Oct 21st Security Incident", October 22, 2026, with continuous updates (advice that customers who signed up before October 21 rotate keys stored on Railway, and the October 26 update stating "Railway is unable to refund customers for spend performed with compromised API keys"; read first-hand by the drafting worker)Read source
- [3] BleepingComputer, "Railway breach leads to $740,000 in fraudulent AI charges", November 10, 2026 (corroborates the report's figures and the "Black October" framing)Read source