Railway final incident report published November 10, 2026, last updated November 10, 2026 at 18:02 UTC; attack October 20 to 21, 2026
They Queried for AI Keys by Name: Railway Final Report Prices a Platform Breach at About $740,000
Railway final incident report, published November 10, closes the forensic loop on its October attack and names the motive in the query logs. The intrusion began at 07:28 UTC on October 20 with a previously unknown flaw in the build infrastructure that partially escaped filesystem isolation and yielded an internal build credential. That credential was trusted beyond its intended scope: it opened stored histories of 353 builds with their variables, and a snapshot of Railway own source code, which the attacker used to find further paths, including a misconfigured OIDC binding that produced short-lived cloud credentials. From an orchestration machine the attacker reached the database holding envelope-encrypted customer variables and, between 04:07 and 07:15 UTC on October 21, retrieved encrypted envelopes and decrypted a subset using a longer-lived credential held on that machine. Railway puts the ceiling at 1.85 percent of workspaces, about 100,000, and is explicit that the figure is an upper bound from environment-level logs, not a confirmed count. The decrypted material included linked-account tokens for 1,852 users, since reset, and the database queries themselves are the intent evidence: the attacker filtered variable names with patterns aimed at AI provider keys, which Railway believes were bound for resale to transfer stations for model distillation work. Unauthorized use of stolen keys is estimated at about $740,000, which Railway is pursuing as refunds and backstopping from its own funds. The attacker was fully evicted by 09:24 UTC on October 21, Railway describes the fight as a contest of agent speed against automated tooling, and it notes that OpenCode, Warp, Fireworks AI and others disclosed similar key thefts between October 6 and 23, assessing this as one of a series of attacks on platforms that hold AI keys.
Executives
The number to carry is not the workspace ceiling, it is the $740,000, because that is what stolen AI keys converted into within days, and Railway is absorbing it. Any platform that stores your teams keys, including build systems, deployment tools and AI gateways, holds spend authority in credential form. Ask for the inventory of where your AI provider keys live, which of them have spending caps, and how fast each could be revoked and replaced. If the answer is a list of consoles nobody owns, that is the finding, and it predates any breach.
CIO / CISO
Extract the control failures in order, because each one is common. A build credential trusted beyond its purpose. Build histories retaining live secrets. Source snapshots reachable with that same credential. An OIDC binding error minting cloud credentials. A decryption-capable credential sitting on an orchestration host. Your program answers are short-lived, narrowly scoped build credentials, secret-free build logs, per-environment keys with no standing decrypt path, and provider-side budget caps and alerts on every AI key. Treat the upper-bound framing as the reporting standard to demand from your own vendors: a ceiling labeled as a ceiling.
Engineers
Rotate as if you are in the subset, because the vendor cannot tell you that you are not. Replace every secret that ever transited a build system you do not fully control, starting with AI provider keys, then database, cloud and payment credentials, and check provider usage dashboards for spend that predates any notice. In your own pipelines, scrub variables from build histories, scope CI credentials to the single job that needs them, and pin OIDC trust to exact repository and branch conditions. Then set the tripwire this attack would have hit: per-key budgets with alerts well below four figures.
Everyone (non-IT)
If you deployed a side project or a work tool on Railway, follow its guidance and rotate the keys and passwords stored there, even if you never received a personal notice, because the company can only bound the exposure, not name every affected secret. The habit generalizes: a key pasted into any hosted tool is a key that tool breach can spend. Where a service offers spending limits on API keys, set one; where it offers separate keys per project, use them, so one leak cannot bill against everything you run.