Cloud hosting provider Railway has published a detailed account of the October security breach that exposed customer environment variables, confirming that the attackers were after one thing above all: AI provider credentials. The company says the stolen keys were used to run up about $740,000 in unauthorized AI usage, and that as many as 100,000 workspaces could have had secrets decrypted.
The incident report, published on November 10, follows a preliminary disclosure on October 22. It describes a 26-hour battle in which Railway engineers fought an attacker that used AI agents to find and chain vulnerabilities across the platform, while the company hardened its systems in parallel.
How the attackers got in
The attack began on October 20, when the intruder exploited a previously unknown vulnerability in Railway’s build infrastructure to partially escape filesystem isolation on a shared virtual machine. That escape yielded a credential the build servers used to authenticate to internal systems, including a registry service for completed builds.
An alert on anomalous API calls paged the on-call engineer at 13:58 UTC on October 20. By then, the attacker had already read the stored histories of 353 builds, including sealed environment variables, through Railway’s self-hosted Temporal task system. Because one of those builds belonged to Railway’s own support platform, the attacker also obtained a copy of the company’s internal monorepo, giving it a privileged view of how the platform works and a map of new routes to try.
The second entry point came through a misconfigured OpenID Connect trust relationship. At 03:26 UTC on October 21, the attacker used it to obtain short-lived cloud credentials, then retrieved internal credentials and an SSH private key, reached a machine that orchestrates customer workloads, and pulled encrypted environment variables from a production database. Between 04:42 and 07:14 UTC, the attacker decrypted a subset of those variables. Railway disabled the credentials at 07:14 UTC and fully evicted the attacker by 09:24 UTC on October 21.
What was taken, and why AI keys were the prize
Railway says database logs show the attacker specifically prioritized AI provider keys, querying variable names with regular expressions and targeting customers with large numbers of variables. Its forensic investigation concluded the credentials were passed on to distributed transfer stations for use in model distillation, a practice in which one model’s outputs are used to train another.
“Based on our forensic investigation, we believe the attacker was specifically targeting AI provider credentials, that they could sell to distributed transfer stations for use in distillation,” the company wrote in the report.
The confirmed impact is significant. At most 1.85 percent of Railway workspaces, about 100,000, could have had environment variables decrypted, though Railway stressed that is an upper bound, not a confirmed count. Linked-account tokens, including bring-your-own-key agent keys and GitHub OAuth tokens, were exposed for 1,852 users. Railway reset every one of those tokens and said it found no logins to Railway accounts using the stolen credentials.
Starting at 09:25 UTC on October 21, Railway asked GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google and Stripe to revoke potentially compromised keys, sharing hashes of every key it held so providers could isolate the blast radius. Unauthorized spend on the stolen keys was estimated at about $740,000. Railway said it is working with providers on refunds and will cover charges from its own balances where providers decline.
Part of a wider wave
Railway places the incident in a broader campaign that security firm Wiz has dubbed “Black October.” According to the report, OpenCode, Warp, Fireworks AI and several other platforms disclosed similar credential thefts between October 6 and 23, and the examples customers shared with Railway included coding-agent requests, reviews of AI-agent behavior for training data, and checks of training tasks and their scoring systems.
GPTOnline reported on November 1 that Wiz had counted nine AI developer platform breaches in the campaign. Railway’s report adds a detail that explains why the platforms were targeted together: the attacker used models with their safety limits removed, driven through an agent harness similar to ARTEX, according to Wiz, turning the intrusion into what Railway called “a contest of agent speed.”
Railway halted builds twice during the incident, invalidated every user session and token on October 21, and restored builds for all plans by 22:49 UTC on October 22 after significantly hardening the infrastructure. The company said all exploited vulnerabilities have since been remediated and that the attacker had no access to any customer data beyond 09:25 UTC on October 21.
Why it matters
The breach shows how AI credentials have become a target in their own right, not just a means to reach something else. A stolen API key no longer only risks a bill: it can feed a distillation pipeline that trains a competing model on a frontier lab’s outputs, which is exactly the use Railway believes its attackers had in mind. For developers, the lesson is concrete. Secrets stored as environment variables in a hosting platform are only as safe as that platform’s isolation, and Railway’s own report concedes its build isolation failed at the first step.
For the industry, the incident is a second warning in a month. The first came from Wiz’s count of nine breached platforms. Railway’s detailed timeline now shows how quickly an automated attacker can move once inside, from a single build escape at 07:28 UTC to decrypted production secrets before 05:00 UTC the next day, and how much of the defense depended on engineers watching the attacker in real time.
