Railway Breach Stole AI API Keys — the Fix Was Impossible

Update, Oct. 22: the catch-22 is partially resolving

Builds returned for Enterprise customers at 03:32 UTC on Oct. 22, according to status-page timelines read by Safeguard.sh and Claroc.io. At 04:17 UTC Railway invalidated ALL Railway API tokens, meaning every Public API integration needs a new token. Redeploys were fixed for Enterprise at 04:52 UTC, deployments progressed slowly through stages at 05:20 UTC, and builds returned for Pro at 06:29 UTC. Free, Trial and Hobby tiers were still pending at last check, and the main incident was still open. The catch-22 is partially resolving: paying tiers can now deploy, which is also when the token invalidation forces every Public API integration to re-token.

By Daniel Rao · October 22, 2026

Read Railway's October 21 security disclosure twice, and the contradiction jumps off the page. In one breath, the cloud platform told every customer to immediately roll their API keys, database passwords and private registry credentials — because an intruder "may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents." In the next breath, it said all deployments were paused and "you will not be able to roll out new versions." On Railway, rolling a key means deploying. Deploying was dead. So Railway ordered the one remediation its own outage had made impossible, and thousands of customers spent Tuesday doing impossible arithmetic with their own infrastructure.

Photo: server racks in a data centre. Railway's disclosure says an unauthorised party may have accessed systems storing customer environment variables. Credit: Edmondo, Wikimedia Commons (CC BY-SA 3.0). Illustrative image.

That catch-22 is the story. But it is not the whole story — because Railway also thinks it knows why it was hit, and its answer is the week's most unsettling pattern in cloud security. While the world's attention was on AI agents doing the hacking, a parallel wave of intrusions has been after something quieter: the AI API keys themselves. Liquid, monetisable, and — as Tuesday proved — sitting in the one store every platform treats as an afterthought until it isn't.

What Railway actually disclosed

The facts, as Railway states them, are narrow and hedged. On the morning of October 21, the company "detected anomalous activity involving systems that store customer environment variables." Environment variables, for the uninitiated, are where developers keep the secrets their applications need to run: API keys, database passwords, registry credentials. The disclosure, signed by Railway's Jacob Cooper, then lands the sentence everyone is parsing: "Our investigation to date indicates that an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents" (blog.railway.com, "Security Disclosure: Wednesday October 21st"). Note the double hedge — may have accessed, and only some of them decrypted. Railway is telling you the worst is possible while declining to say how likely it is.

What Railway did not say is just as telling. No named attacker. No stated intrusion method. No exposure window. No number of affected users — "while our initial analysis suggests the impact may be limited to a subset of users," the company adds, before recommending that all users rotate everything as a precaution. And the direct email contact with confirmed-affected customers? Promised — "we will contact those customers directly by email" — but not yet confirmed as done. We pulled up Railway's disclosure ourselves on Thursday morning: it is still live at its 22:12 UTC October 21 update, with no follow-up "all clear." The investigation reads as ongoing.

The status timeline fills in the day's shape. The incident opened at 07:24 UTC; by 09:28 the dashboard, API and CLI were down and new builds were paused in every region. The API came partly back at 11:33, but builds stayed frozen. At 20:19, Railway invalidated every OAuth session — customers were signed out mid-incident. The disclosure followed at 20:44. Overnight, the company started rotating all storage bucket credentials (22:10), warned that its own staff-led revocations might show up in customer audit logs (22:45), published 13 rotation guides covering Postgres, MySQL, MongoDB, Redis and usage checks for OpenAI, Anthropic, Grok, OpenRouter, Stripe, AWS, GCP and GitHub (01:22), and at 04:17 invalidated all Railway API tokens — every public API integration needed a new token. Enterprise builds were restored around 03:32 and Pro around 06:29; Free and Trial tiers were still pending at last check, with the main incident still open. This is a platform Railway says serves 2 million builders and tens of thousands of companies, up to Fortune 500 scale.

Photo: rows of server racks in a data centre. Railway paused all deployments platform-wide while it investigates the breach. Credit: Wilweterings, Wikimedia Commons (public domain). Illustrative image.

The catch-22: rotating keys takes a deploy

Here is where the disclosure's two halves collide. "All deployments are paused while we investigate," the company wrote. "Until builds are restored, you will not be able to roll out new versions." And yet: "we strongly recommend that you immediately roll all environment variables, including any API keys, stored in Railway, as well as any private registry credentials." Immediate rotation. No way to ship it.

Nobody lived that contradiction more publicly than Theo Browne. The developer and streamer started filming at about 5:30pm on October 21 — hour sixteen of the outage, seventeen-plus by the time he stopped — and worked through the dilemma on camera. Rotating a key requires a deployment, he explained on his podcast, as reported by finance.biggo.com; deployments were down; so the only options were leaving services running with potentially exposed database passwords, or taking the services down and waiting. He did the rolling first — every key he could roll — and then tore his own services down, because the deploy path was closed. His stack was not trivial: Lakebed (T3 Cloud), Slop House analytics, Postplan, an authentication platform, page hosting, a Triviago build, a video pipeline. And Railway's official notification email? It arrived roughly an hour after he had already rolled his keys himself.

That detail is worth sitting with. A platform's customers were self-triaging a potential secrets breach on a livestream, an hour ahead of the platform's own email. The remediation pipeline was the casualty of the outage it was meant to fix. Browne also drew a line people keep blurring: he framed Railway's incident and the week's simultaneous wave of critical software vulnerabilities — the PHP2Shell disclosures and their cousins — as two unrelated stories, the platform-key theft being the more dangerous of the two. We agree, and we covered that vulnerability wave amid the same week's wave of critical software vulnerabilities — but he is right that conflating them misses the point. One is about bugs in code. The other is about the keys to the kingdom.

AI keys are the loot, not the database

Railway's disclosure contains one more sentence that deserves to be read slowly: "We believe this is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers" (blog.railway.com, "Security Disclosure: Wednesday October 21st"). Not databases. Not source code. AI inference keys — the credentials that let you spend someone else's money on large-model compute.

The through-line is five days old. On October 17, five days earlier, OpenCode disclosed a strikingly similar attack: an intruder reached a legacy Console system on the night of October 16, exposing OpenAI, Anthropic and Google provider keys in Console workspaces for roughly 1.4% of its users, in what the company called "a large scale distillation attack" — and it said it was working with Anthropic, OpenAI and Google on the fallout. The shape is identical: skip the database, take the AI keys. Browne's read was blunter still — he argued a black market for Anthropic and OpenAI keys had claimed another platform.

Two honest caveats, because the industry deserves them. First: no source links the OpenCode and Railway incidents to the same actor — OpenCode never confirmed a link, and Railway named nobody. Railway says it believes this is part of a series; the OpenCode disclosure five days earlier is corroboration of the pattern, not proof of a shared attacker. Second: keep this week's two AI stories separate in your head. Our October 22 reporting covered a separate, simultaneous campaign in which AI agents were the attackers — Storm-0940 automating break-ins at machine speed. This story is the mirror image: AI API keys as the loot. Agents holding the crowbar; keys as the cash drawer. Different crimes, same week, same uncomfortable conclusion: the AI economy's most liquid asset is a string of characters, and attackers have noticed.

Why keys and not data? Because keys are better than data. A stolen database has to be fenced; a stolen Anthropic or OpenAI key is spendable compute, instantly, anywhere — the "distillation attack" framing from OpenCode says it plainly, model outputs siphoned at someone else's expense. Railway's own remediation tells you where it thinks the blast radius is: it "notified these upstream providers to revoke all keys proactively." No public statement from OpenAI or Anthropic on Railway keys has surfaced as of this writing — and do not confuse this with Anthropic's proactive revocations earlier in the week, which were tied to the OpenCode incident, not Railway. Two incidents, two sets of keys, one very busy week for AI-provider trust and safety teams.

The unconfirmed pile: crypto drains and OpenRouter

Everything above is what Railway or a named outlet has put on the record. Now the part of the story that is still smoke — and it is substantial, so it belongs here, clearly labelled.

First, the money. Blockchain investigator Taylor Monahan has linked roughly $371,000 in crypto drains across 19 EVM-compatible chains — more than 500 transactions — to the incident, with the first known theft transaction timestamped 19:36 UTC on October 21, about two hours before Railway's disclosure. The strongest secondary reporting comes from The Defiant, which wrote that "a developer alleges $370,000 was stolen through Railway-stored secrets," describing an onchain record of a large transfer to an address flagged by an investigator. Related chatter cites an Onchain Lens report of a suspected attacker wallet moving at least $369,300 to HitBTC and other addresses, receiving funds from a wallet linked to a known ledger drainer — a connection that stays unconfirmed. Here is the flag in plain language: Railway itself has not confirmed any crypto theft, and its disclosure, per crypto press coverage, "did not identify affected crypto or web3 projects, wallet-signing keys or cryptocurrency losses." Treat the drain as alleged and investigator-linked, not as fact. But note the timing: if the theft transaction is real, the money was moving before customers were told.

Second, OpenRouter. On October 20, dark-web monitoring chatter named the Stripe-owned AI gateway as a breach victim; a law firm said it was investigating, while adding that "little information is available at this time." One cited link hints at around 252,000 users and 208,000 API keys — but, in explainx.ai's words, "On October 20, dark-web monitoring sites reported OpenRouter had been named as a breach victim... OpenRouter had not confirmed a breach when we published" (explainx.ai, "Railway Hack, OpenRouter Claim: Your AI Keys Are the Target"). OpenRouter had not confirmed any breach at the time of that writing. Note the one connection that is real: Railway's own rotation guides list OpenRouter among the AI providers whose usage customers should check. That is guidance, not evidence of compromise. Do not let anyone tell you otherwise.

What Railway customers should do now

The actionable core survives all the hedging. Rotate every environment variable stored in Railway — API keys, database credentials, private registry credentials — and review service logs for unusual activity. Railway's 13 published guides walk through credential rotation for Postgres, MySQL, MongoDB and Redis, plus usage checks for OpenAI, Anthropic, Grok, OpenRouter, Stripe, AWS, GCP and GitHub. Expect oddities: Railway warned that its own staff-led bucket credential rotations may appear in your audit logs, and the 04:17 UTC invalidation of all Railway API tokens means any public API integration needs a fresh token. If you use Railway's OAuth, you were signed out when sessions were invalidated at 20:19 UTC on October 21 — that was deliberate, not a glitch.

And if you are on the Free or Trial tier: at last check, builds had not yet been restored for you, while Enterprise and Pro were back. The rotation guidance applies to everyone, but the deploy path to act on it was still reopening in stages. Check status.railway.com before assuming your tier is clear.

Our read: the remedy shared the blast radius

There is a temptation to file this as "platform gets hacked, platform freezes everything, standard incident response." That would be generous. The sequencing here was botched in a way that should embarrass the industry: the single most sensitive store on the platform — the environment-variable vault holding every customer's secrets — was compromised, and the incident response froze the exact mechanism customers needed to mitigate it. Telling people to rotate keys while blocking deploys is not caution; it is a design failure made visible. The deploy pipeline and the secrets store must be separable failure domains. On October 21, they were one blast radius, and customers paid for it in downtime they chose themselves — Browne tearing down his own services on a livestream, an hour before the official email arrived, is the image this incident deserves to be remembered by.

The deeper shift is the target. Attackers spent a decade stealing databases; now they are stealing the keys that buy intelligence. An AI inference key is colossally more useful than a row of user records — it is instant, anonymous, globally spendable compute, and the victim pays the bill. Railway believes platform companies are being hit in series for exactly this. OpenCode, five days earlier, told the same story with different keys. Whether or not the two incidents share an attacker, they share a thesis, and the thesis is winning: the crown jewels of the AI era are not in the database. They are in the environment variables. Platforms that treat secrets storage as plumbing — and incident response as "freeze everything" — are going to keep learning this lesson the expensive way, one impossible rotation at a time.

Related: OpenCode's 'Distillation Attack' Drained Users' AI Keys · Microsoft: China's Hackers Let AI Agents Hit 2,250 Tenants · AI found 'PHP2Shell' — the critical flaw hiding in the language behind 70% of websites

Sources: Railway, "Security Disclosure: Wednesday October 21st" (Oct 21, 2026, updated 22:12 UTC); status.railway.com timeline via relay reports; explainx.ai ("Railway Hack, OpenRouter Claim: Your AI Keys Are the Target"); The Defiant (Oct 22); finance.biggo.com's relay of Theo Browne's October 21 podcast; secondary reporting on OpenCode's October 17 disclosure. Our own October 18 reporting on OpenCode and October 22 reporting on Storm-0940. Analysis is the author's own.

Daniel Rao covers AI, autonomous agents and the business of technology for TechPulse USA.

 

Railway breach: your questions, answered

Was Railway hacked?

Railway's disclosure wording is that an attacker "may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents," in the words of CEO Jacob Cooper. The double hedge — "may have" and "some of them" — is load-bearing.

Do I need to rotate my keys?

Yes: every environment variable and registry credential should be rotated; Railway published 13 guides for the rotation.

Is Railway still down?

Enterprise and Pro builds were restored on Oct. 22, while Hobby, Free and Trial tiers were still pending at last check and the main incident was still open.

Is this the same as Indian Railways?

No. Railway here is the cloud platform at railway.com, not Indian Railways or IRCTC.