Railway traces AI key theft to a build isolation escape

Railway has published its full incident report on the October intrusion that exposed customer secrets on the cloud hosting platform. Released at 14:00 UTC on 10 November and announced on X, it describes for the first time how the threat actor got in: a flaw in Railway's shared build machines, then a misconfigured cloud login binding found by reading Railway's own source code. It also gives the first figures for stolen tokens and for money spent on stolen AI keys.

From a build to the source code

According to the report, the threat actor began probing Railway's build infrastructure at 06:50 UTC on 20 October. Builds from different customers then ran side by side on the same virtual machines. At 07:28 UTC the threat actor exploited a previously unknown flaw to partly escape a build's filesystem isolation and read files on the host, including a credential the build servers use to push finished images.

That credential was meant only for registry pushes, but Railway's internal Temporal cluster, which schedules build tasks, accepted it as a trusted client. Through it the threat actor read the stored histories of 353 builds, which contain build variables and sealed secrets, and pulled a copy of Railway's internal monorepo from a build cache. An on-call engineer was paged at 13:58 UTC over unusual calls to the build registry. Railway halted builds, fixed the escape and replaced the credential at 17:28 UTC, without yet knowing the threat actor had its code.

From the code to customer secrets

Railway says the threat actor then used the source code to look for new ways in, probing endpoints that had not been used for months or years. It found an erroneously defined OIDC binding in one of Railway's cloud environments, which at 03:26 UTC on 21 October gave it a short-lived cloud credential meant for Railway's deployment pipeline. With that it took two more credentials from the cloud environment and logged in over SSH to a machine that runs orchestration tasks for Railway's fleet. A file on that machine held a longer-lived credential that could decrypt customer variables.

Each environment's variables are encrypted with their own key, which is itself encrypted by a root key in a cloud key management service. Between 04:07 and 05:21 UTC the threat actor pulled encrypted variables from the production database, selecting rows whose names matched AI provider keys and favouring customers with many variables. From 04:42 UTC it used the stolen credential to decrypt some of them, until Railway disabled all cloud credentials at 07:14 UTC. Railway says the threat actor had no access to customer data after 09:25 UTC on 21 October.

What the full report changes

The preliminary report of 23 October gave a timeline starting with the 13:58 UTC page and said decryption came after 05:27 UTC. The full report corrects both: decryption began at 04:42 UTC, and the threat actor's first sign-ups were on 18 October, two days before the timeline began, when automated defences stopped its early attempts. The ceiling on exposure is unchanged: at most 1.85% of workspaces, about 100,000, could have had any variables decrypted, an upper bound because the logs identify environments, not individual variables.

New in the report: the decrypted data included linked-account tokens, bring-your-own AI agent keys and GitHub OAuth tokens, for 1,852 users. Railway reset all of them and says none was used to log in to a Railway account. It estimates unauthorized spend on stolen keys at about $740,000. AWS Bedrock and Google Gemini are refunding fraud under their existing policies and OpenAI and SpaceXSI are reviewing claims case by case.

Railway says it will cover Anthropic costs while talks continue and all OpenRouter costs, since OpenRouter is keeping its no-refund policy. Customers can report charges through a form in the report.

Part of a wider campaign

Railway believes the keys were wanted for distillation, using frontier models to train other models, and that they were passed to services that relay or resell AI access; it has not established whether the threat actor ran those services. It links the attack to similar thefts at OpenCode, Warp, Fireworks AI and others between 6 and 23 October. Wiz's Black October tracker lists at least nine AI developer platforms that disclosed incidents in October. Railway notes that this research does not itself attribute the Railway incident.

Every build now runs in its own short-lived virtual machine with a credential that can only push one image, and only the secrets service can reach the keys that decrypt data keys. Railway has filed a complaint with the FBI's IC3, and a forensics firm's investigation is still under way.