Picture this: you wake up, open your cloud dashboard, and discover someone has been spending your money all night. Not on a shopping spree. On artificial intelligence.
That is the nightmare thousands of developers faced after Railway, the popular hosting platform, revealed the full scale of a breach that began on a quiet Tuesday morning in October. The final incident report, published on November 10, reads less like a routine security update and more like a warning for the whole industry.
Hackers broke into Railway’s build systems, decrypted customer secrets, and went hunting for one thing above all: AI provider keys. By the time they were thrown out, those stolen keys had generated an estimated $740,000 in unauthorised charges.
A Quiet Tuesday Morning Turns Into a 26-Hour Fight
The attack began on October 20 at 07:28 UTC, according to Railway’s report. The first probes had started even earlier, at around 06:50 UTC, as the attacker tested the company’s build machines for a way in.
What they found was a previously unknown flaw in Railway’s multi-tenant build system. In plain terms, the wall that is supposed to keep one customer’s build from seeing another customer’s files did not hold. The attacker slipped through it and grabbed an internal build credential.
That credential carried far more trust than it should have. From there, the intruder reached stored build histories and Railway’s key-management service, which could decrypt some of the secrets it found.
Railway’s engineers fought back for roughly 26 hours. The attacker was fully evicted on October 21 at 09:24 UTC, and the platform’s builds were fully restored the following day, on October 22.
Three weeks later, the company published its final report. The numbers in it are worse than the first disclosures suggested — and they tell a story that goes well beyond one hosting platform.
How the Railway Breach Happened
Railway has not yet explained exactly how the attacker found the flaw, or how the encrypted values were decrypted. What the report does say is that the intrusion used two weaknesses in combination.
The first was the build-system flaw that let the attacker partly escape filesystem isolation. The second was a weakness in cloud identity that opened the door to internal systems. Together, they turned a single foothold into access to stored secrets.
The company says it has now closed every weakness the attacker used. It has also rebuilt internal tooling, rotated its infrastructure credentials, and accelerated a move to isolated, single-tenant build machines — so one customer’s build can no longer share space with another’s.
What the Attackers Actually Took
The most alarming figure in the report is the exposure cap: at most 1.85 percent of Railway’s workspaces — roughly 100,000 — may have had environment variables decrypted. That number is a ceiling, not a confirmed count.
Railway has not confirmed how many workspaces were actually hit. Its logs identify environments rather than individual variables, so the true figure could be far lower. But even the possibility of 100,000 exposed workspaces shows the scale of what was at stake.
Environment variables are the quiet workhorses of modern software. They hold API keys, database passwords, and service tokens — the credentials an app needs to talk to other services. In this case, the attacker was not after all of them equally.
Database queries run by the intruder specifically searched for AI provider credentials. Railway believes the keys were gathered for resale, and possibly to feed model distillation pipelines — a way of training cheaper AI models on the output of expensive ones.
Beyond the environment variables, the attacker read the history of 353 builds, secrets included. Linked-account tokens belonging to 1,852 users were also exposed, including GitHub OAuth tokens and bring-your-own-keys for AI agents. Railway has reset all of those tokens.
Two things, the company stresses, did not happen. Its customer database was not accessed, and it has seen no account logins carried out with the stolen credentials.
The $740,000 Bill Nobody Expected
The most concrete damage is the money. Stolen keys were used to run roughly $740,000 of unauthorised AI usage across providers, according to Railway’s estimate.
That figure is what happens when stolen keys reach adversarial hands. AI usage is billed by the token, so a key with generous limits can burn through thousands of dollars in hours — and the owner only finds out when the invoice arrives.
Railway’s position on who pays has changed since the first disclosure. On October 26, the company said it would not cover the charges. In the final report, it reversed course: it will absorb the cost itself if providers do not refund it.
Some providers have already started. Railway says AWS Bedrock and Google Gemini have begun issuing fraud refunds, while OpenAI and SpaceXSI are reviewing claims case by case. The company is working directly with AI providers on the refunds.
Why AI Keys Are the New Target
The Railway breach did not happen in isolation. It was one of a wave of credential thefts that hit the AI ecosystem in October, and the pattern is hard to ignore.
Just weeks earlier, Fireworks AI disclosed a breach that exposed customer datasets and model weights, while OpenCode confirmed on October 17 that AI keys stored in its console may have been exposed. Researchers also documented the Grok Build leak, which left tens of thousands of apps reachable without any sign-in.
The common thread is simple: AI keys are valuable. They unlock paid compute, they can be resold, and they can feed rival model training. Where older breaches chased credit card numbers, these attackers chase the keys that power the AI boom.
The agent layer makes the problem worse. AI coding agents sit between a foundation model and a user’s live environment, and they need credentials to do anything useful. That concentrates secrets in one place — and when that place is breached, the spill is industrial in scale.
What Railway Is Doing Now
Railway says it has closed the vulnerabilities and configuration weaknesses used in the attack. Beyond the fixes, the company has rebuilt internal tooling and rotated infrastructure credentials across its systems.
The bigger change is architectural. Railway is accelerating its move to isolated, single-tenant build machines. In that setup, each customer’s build runs on its own machine, so a flaw in one build cannot reach another customer’s files.
It is also working with AI providers on refunds, and it has promised to cover losses where providers decline to reimburse customers. That commitment is a notable shift from its original stance, and one that other platforms may now be judged against.
Still, questions remain. Railway has not said how the attacker got in, or how the decryption worked. Until those details are public, other platforms running similar multi-tenant build systems cannot be sure the same flaw does not exist in their own infrastructure.
What to Do If You Used Railway
If you hosted anything on Railway before late October, the advice is straightforward: rotate your secrets. Railway told all customers to change their secrets after the first disclosure, and the final report makes that advice more urgent, not less.
Start with AI provider keys, then GitHub tokens and database credentials. Check your AI provider billing dashboards for usage you do not recognise, and contact the provider if anything looks wrong — Railway says fraud refunds are already flowing for some of them.
Longer term, the lesson is about how secrets are stored. Keys kept in environment variables are convenient, but they are also a single point of failure. Scoping keys to the smallest possible permissions, setting spending limits, and rotating them regularly all limit the damage when a breach happens.
The Railway breach is a reminder that the AI boom has created a new kind of loot. The models get the headlines, but the keys that pay for them are what attackers are stealing — and $740,000 is the price tag this time.
Source: MLQ, reporting on Railway’s final incident report and BleepingComputer’s coverage.
