TL;DR: Railway, the cloud platform thousands of developers use to deploy apps and databases, has confirmed that a zero-day in its build infrastructure let an attacker read host files, chain into an internal task-management system, and pull the keys needed to decrypt customer environment variables in a production database. Railway says environment variables tied to as many as 100,000 workspaces could have been exposed, and the attacker used stolen AI API keys to run up roughly $740,000 in unauthorized AI usage in about 26 hours before the company shut the hole down.
Railway published an incident report this week walking through exactly how its October breach unfolded, and it reads less like a typical credential leak and more like a slow-motion escape attempt that kept working. According to the report, an attacker exploited a zero-day that let them “partially escape filesystem isolation” on one of Railway’s build hosts, the shared machines that spin up containers every time a customer pushes new code. That escape gave them read access to files on the host VM, including credentials the build servers use to reach a handful of internal systems.
A small crack turned into a full internal tour
Those first credentials didn’t work in most of the places the attacker tried them. What they did unlock was Temporal, Railway’s internal task-management system. Poking around inside Temporal, the attacker found a stored copy of Railway’s own codebase, and that copy had a misconfigured authentication setting. That misconfiguration handed over temporary cloud credentials, and those credentials opened the door to more internal systems, among them a production database holding encrypted environment variables for customer workspaces, along with the information needed to decrypt them.
Environment variables are where developers stash exactly the kind of thing you don’t want strangers reading: database passwords, payment-processor secrets, and increasingly, API keys for AI services like OpenAI, Anthropic, and various coding-agent tools. Railway’s report says that’s precisely what the attacker went after. The company estimates variables tied to up to 100,000 customer workspaces “could have been decrypted.” That’s an upper bound on exposure, not a confirmed count of who actually got hit, but it’s the number Railway is using to size the blast radius.
Why the bill landed on AI providers
Once the attacker had working AI API keys in hand, they didn’t sit on them. Railway’s report describes roughly $740,000 in fraudulent charges tied to coding-agent sessions and AI-training-pipeline usage, racked up over a stretch the company clocks at about 26 hours, from roughly 07:28 UTC on October 20 to 09:24 UTC on October 21. Railway’s engineers describe the response as a race against the clock, with staff working shifts to contain the intrusion while it was still live. The report’s own phrase for it: “the escalating situation became a contest of agent speed.”
That detail matters, because Railway and the security firm Wiz, which is credited in the report for the attribution, say the attack itself leaned on automation. The attacker reportedly ran what the report calls “abliterated models,” meaning open models stripped of their usual safety guardrails, through a harness Wiz says resembles ARTEX, a known AI-assisted attack toolkit. Railway stops short of saying definitively where the stolen keys ended up, but it floats the possibility that they were resold on the black market, potentially to support model distillation, where one model’s outputs get mined to help train another. The company is careful to call that theory unprovable rather than confirmed.
It’s a pattern that’s shown up more than once this year: attackers treat compromised AI credentials less like stolen loot to cash out quietly and more like compute to spend immediately. A study making the rounds this month found that AI agents will hand over secrets to other agents that simply ask for help, and the Railway incident is a reminder of what happens once those secrets are loose: the race isn’t to find a buyer, it’s to burn through the access before anyone notices and rotates it.
What Railway is doing about the bill, and what it means for everyone else
Railway says it has closed the exploited vulnerabilities, rebuilt the affected infrastructure, and rotated every credential the intrusion touched. On the financial side, the company says it’s working with AI providers to get the fraudulent charges reversed, and that it will personally cover whatever losses those providers decline to refund. That’s a notably direct commitment for a platform company to make, and it suggests Railway sees the reputational cost of leaving customers holding a six-figure AI bill as worse than eating it.
For Railway’s customers, the practical advice is blunt: rotate anything you ever stored as an environment variable on the platform, starting with AI provider keys, database credentials, and anything tied to billing. Even with Railway’s upper-bound framing, “up to 100,000 workspaces” is a big enough number that assuming you’re fine because you haven’t heard otherwise is a bad bet. The company has reportedly been notifying affected accounts directly, but given how many platforms store secrets the same way Railway does, this is also a decent moment for any team to check whether its own build pipeline treats environment variables as sensitive as the API keys sitting inside them actually are.
This isn’t an isolated design flaw either. Hardcoded or carelessly stored credentials keep turning up as the quiet cause behind headline-grabbing breaches, the same root problem that showed up when Wyndham exposed guest data through a hardcoded password rather than anything more exotic. The common thread across both incidents is that the actual break-in technique is almost beside the point. What turns a contained bug into a six-figure incident is how much trust got stored in one place, unencrypted or easily decryptable, waiting for someone to find the right door.
The bottom line
The technical chain here is almost elegant in a bad way: one small filesystem leak, chained through an internal tool, into a misconfigured auth check, into the one database that mattered. None of the individual steps sound catastrophic on their own. Strung together, they added up to six figures in stolen AI compute and a six-month cleanup job for Railway’s trust with developers. If your team stores AI API keys as plain environment variables on a shared platform, and most teams do, this is the incident that should finally get those keys rotated on a schedule instead of only after a breach notice lands in your inbox.
The Teck Hustlers Editorial Team covers technology, business, finance and gaming news for readers who want the story behind the headline. Every article is researched, written and edited by our in-house team, checked against company announcements, filings and reputable reporting, and updated when new facts emerge. We focus on what each development means for founders, professionals, investors and everyday users. Have a tip or a correction? Reach us through our contact page.
