The Railway breach explained: what leaked and what to rotate

On 21 October 2026 an attacker got into the Railway systems that store customers' environment variables, and for some customers they walked away with the decrypted values. Railway believes AI provider keys were the target¹. I read Railway's own notices, its status page, the press, and the Hacker News thread where a Railway employee commented. This post is what I came away with. Every claim that needs one has a numbered reference.

The research cut-off is 23 October. Railway has not yet published a root cause, so check the references before you act on anything here.

The short version

• What leaked: environment variables, which usually hold API keys, database URLs and passwords, cloud credentials, registry tokens and sometimes crypto wallet private keys.¹
• Damage so far: about $371,000 drained from crypto wallets whose keys were stored on Railway, according to investigator Taylor Monahan. Developers also reported misused AI keys, and the Postiz service shut down after warnings from Anthropic and Stripe.^{11, 14}
• Platform impact: builds and deploys were paused in every region for about 18 hours for Enterprise customers and about 37 for Free and Trial. All Railway API tokens and OAuth sessions were cancelled, and bucket and GitHub credentials were reset.²
• Context: it came five days after the OpenCode Console breach, which also exposed users' AI provider keys.²⁰

Scale is hard to pin down because outlets disagree. BleepingComputer cites about 4.8 million users and more than 16 million hosted services, while OpenClassActions puts Railway at more than 2 million developers as of January.^{13, 14} CEO Jake Cooper told TechCrunch the company will publish a postmortem.¹²

Timeline of the Railway breach

Railway froze builds around 09:30 UTC on 21 October. The first wallet drain came at 19:36 UTC, and the public security notice followed at about 22:00 UTC. All times below are UTC and come from the status page unless another source is cited.²

The wallet drain began about ten hours after the build freeze and more than two hours before the public notice. Freezing deploys did not stop an attacker who already held decrypted secrets.

What was exposed

Railway confirms access to encrypted environment variables. It also says the attacker "obtained the decrypted contents" of some of them, and has not said which ones or how many.¹

Environment variables are where most apps keep everything sensitive. On Railway that usually means DATABASE_URL, AI provider keys (OpenAI, Anthropic, OpenRouter, xAI), Stripe keys, AWS and GCP credentials, webhook and JWT secrets, SMTP passwords and, for some crypto projects, wallet private keys. A database password is only useful if the database is reachable, so Postgres with Public Access turned on is at higher risk than one on the private network.

Railway says the impact "may be limited to a subset of users" and will email the accounts it confirms. It still tells every customer to rotate.¹

How the attacker got in

We do not know yet. Railway has not published a root cause. What exists falls into four layers of reliability.

Confirmed by Railway

• The anomalous activity was in "systems that store customer environment variables".
• The variables were encrypted at rest, yet the attacker still got plaintext for some of them.
• Railway has not given the date the attacker first got in.¹

Said informally by a Railway employee

A person posting as ndneighbor on Hacker News, who identified as a Railway employee, said the attacker was highly motivated and tried to move sideways inside Railway's systems. They said AI API credentials were the primary goal and that the delay in advising rotation was deliberate, because Railway could not yet confirm the breach was contained. This is one username's account, not an official statement.²³

Inference

Plaintext for only some secrets points away from a simple database dump and toward the decryption path: whatever is allowed to call the key-management service, or the credentials that service runs as. The CyberSec Guru suggests compromised code inside the decrypting service or stolen short-lived service-account credentials. That is outside analysis, not a Railway finding.¹⁶

Outside theories

Several Hacker News commenters, including one posting as tptacek, argued the attacker most likely hit the storage backend, probably a database, so how variables are injected into containers matters less. One commenter claimed Railway's default databases are reachable from the internet, so leaked database passwords may also have exposed the databases themselves. Another disputed that, saying they were private by default. Railway has confirmed neither.²³

The wider campaign: why AI keys

Railway says the breach is "part of a series of attacks recently targeting platform companies" aimed at "AI inference providers". Platforms that hold many customers' AI keys are being targeted to get at those keys. Railway names no attacker.¹

• OpenCode Console, 16 October. An intruder reached a legacy system being decommissioned and exposed OpenAI, Anthropic and Google keys saved by about 1.4 percent of Console users. OpenCode called it "a large scale distillation attack". Co-founder Dax Raad said the attackers used AI agents and kept at it for at least 48 hours.^{17, 18}
• Why AI keys. Theo Browne argues a standing black market buys frontier-model output to train cheaper models, a practice called distillation. By his estimate a stolen key yields hundreds to a few thousand dollars before it is revoked. These are his estimates, not measured figures.¹⁷
• What else they power. Bitsight found a criminal tool, MONST3R-AI, sold between February and August 2026. Buyers plug in stolen OpenAI, Anthropic or Google keys, and the victims pay for its automated scans.¹⁹
• Fireworks AI, 6 October. Compromised internal credentials gave access to environment variables in evaluation jobs for a limited number of customer accounts, so stored API keys and tokens were probably captured. This comes from secondary coverage only.²⁴
• CISA context. TechCrunch adds that CISA recently warned of large-scale attacks on US companies by China-based AI firms trying to improve their own models. No source I found ties that to Railway or OpenCode.¹²

Any service that stores customers' AI keys is now a target: hosting platforms, AI IDE consoles and LLM gateways.

Damage so far

The only measured loss is about $371,000 taken from crypto wallets. AI key abuse has been reported but has no confirmed total.

• Crypto wallet drain. Taylor Monahan tracked more than 500 transactions draining over 200 wallets on at least 19 EVM chains. The money went to one address through what looks like a standard sweeper script. Railway has not confirmed the link or the figure. A wallet key cannot be rotated: the only fix is a new wallet and moving every asset off every chain.¹¹
• AI key abuse ("LLMjacking"). Railway's guides tell customers to check OpenAI, Anthropic, xAI, OpenRouter and Stripe for usage they do not recognise.^{7, 8}
• Customer shutdowns. Postiz founder Nevo David shut the service down for all customers after emails from Anthropic and Stripe said its keys were compromised.²⁵
• Legal. As of 22 October no lawsuit or class action had been found.¹⁴

Unverified user reports

Commenters on the Hacker News thread describe what they saw. None of it is confirmed by Railway or the providers. One reported attackers reading their S3 buckets, using an OpenAI key that OpenAI then revoked automatically, and running read-only commands on a Valkey instance. Others reported OpenRouter disabling Railway-linked keys and an Anthropic key disabled about three hours after Railway's notice, after roughly $20 of Opus usage. One said old bucket keys still worked after rotation attempts.²³

Outage cost

Redeploy, pre-deploy commands and the deploy queue were degraded into 22 October, and every integration using a Railway API token broke until it was given a new one.²

Railway's response and the criticism

Railway froze the platform, reset every credential it controls and warned AI providers so they could revoke keys. The main criticism is that it took more than 12 hours to tell customers why.

What it did

• Froze builds and deploys in all four regions to stop changes and preserve evidence, then restored them by plan tier.²
• Warned upstream AI inference providers so they could revoke exposed keys on their side.¹
• Cancelled all OAuth sessions (21 October) and all Railway API tokens (22 October).²
• Reset every bucket's credentials in every environment and cancelled stored GitHub tokens. Audit logs show these resets as "Railway Staff", so customers can tell them apart from attacker activity.³
• Published guides for AWS, GCP, GitHub and bucket checks, then for databases and AI providers.^{4, 5, 6, 10}

Criticism

• Silence. For about 14 hours the status page said only "issue identified", from 07:24 until the security notice around 22:00 to 22:10.
• Theft before disclosure. Wallets were being drained more than two hours before customers were told to rotate.¹¹
• Could not rotate. With builds paused, customers who did rotate could not redeploy to use the new secrets until their plan tier came back.
• Rotation trap. Commenters said they rotated keys early and broke their apps because deploys were paused and the notice did not warn them.²³
• Support down. The support site was down for much of 21 October.
• Second incident this year. On 30 March 2026 a CDN configuration change cached responses for about 0.05 percent of domains with CDN disabled and served them to other visitors for 52 minutes.⁹

What to do now if you use Railway

Rotate every secret you have stored in Railway, highest-value first. Check each provider's logs before you delete the old key, because deleting it can also delete the evidence.

1. Inventory. List every variable in every service and environment, including shared variables and registry credentials.
2. Wallet keys first. Funds cannot be recovered once moved. Create a new wallet on a clean machine and move all assets on every chain.
3. Capture evidence, then revoke. For each key, pull its usage history, then create the replacement and revoke the old one.
4. Database passwords. Use Regenerate in the Database tab. It changes the password and DATABASE_URL together but restarts the database and drops open sessions. Turn off Public Access if you do not need it.
5. Redeploy. Containers only read variables at startup, so nothing changes until each service redeploys.
6. Repair what Railway reset. Create new Railway API tokens for CI, reconnect GitHub and re-enable autodeploy, and copy new bucket keys into anything outside Railway.
7. Review logs. Check the Railway audit log and each provider's logs for the time since 21 October, and export them before plan retention deletes them.

Not every secret carries the same risk or the same rotation cost. This chart rates the common ones. The ratings are my own judgment from the notes in this article, not measured data.

Provider checklist

Open questions

Neither a postmortem nor the Preliminary Incident Report was out when I last checked. Until they answer these, assume the worst for your own secrets.

• Way in: stolen staff or service credentials, a supply-chain package, or a bug in the variables service?
• First access: when did access begin? The exposure window decides how far back your log reviews should go.
• Scope: which customers, and how many variables, were decrypted? Was it targeted (AI and wallet keys) or bulk?
• Other data: were build logs, source or database volumes touched?
• Shared attacker: is it the same actor as the 16 October OpenCode breach?
• Crypto theft: does Railway confirm Monahan's link and the $371K total?
• Databases: were Railway-hosted databases reachable with leaked passwords?
• Prevention: what changes stop a repeat, such as per-workspace keys, short-lived secrets or alerts on plaintext reads?

Every claim in this piece traces to one of 25 references. The chart shows who they are: Railway's own pages, the press, and analysis or community threads, which I treat as weaker evidence.