Railway's 12-hour gap: breach, then $371K crypto drain

Railway, the popular app deployment platform used by thousands of AI startups and indie hackers, disclosed a security breach on October 21, 2026 that may have exposed customer environment variables — including API keys, database passwords, and private registry credentials. Blockchain investigator Taylor Monahan has since linked the incident to approximately $371,000 in cryptocurrency theft across more than 500 transactions and at least 19 EVM-compatible networks.

The timeline is uncomfortable. Railway paused all builds at 07:24 (UTC) on October 21. By 09:28 (UTC), its API, CLI, dashboard, and deployment services were all degraded. The first known cryptocurrency theft transaction — traced to attacker address 0xd9773325282874d18cb83f1fe50f14c39750b2ee — happened at 19:36 (UTC). Railway didn't publish its security disclosure until approximately 21:51 (UTC), more than two hours after the money started moving.

What Railway said

In a security disclosure signed by Jacob Cooper and published at approximately 21:51 (UTC) on October 21, Railway said it had "detected anomalous activity involving systems that store customer environment variables" earlier that morning. The investigation indicated that "an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents."

The line that should worry every AI builder: "We believe this is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers."

Railway said it had notified upstream AI providers to revoke keys proactively. While initial analysis suggested the impact "may be limited to a subset of users," the company recommended that all users immediately rotate every environment variable, API key, and private registry credential stored on the platform.

The crypto drain

Monahan's on-chain analysis, published October 22, paints a more concrete picture of the damage. The attacker used what appears to be a standard wallet sweeper script — not custom malware built for this incident — to drain funds from private keys that had been stored in Railway environment variables.

Source: Taylor Monahan, via crypto.news, October 22, 2026.

Railway has not independently confirmed the crypto losses or established how the attacker obtained the wallet credentials. The $371,000 figure remains an external estimate, and it's possible more wallets were compromised than Monahan has identified.

The 12-hour gap nobody is talking about

Railway paused builds at 07:24 (UTC). The first crypto theft didn't happen until 19:36 (UTC) — 12 hours later. That gap raises a question: what was the attacker doing during those 12 hours?

The most likely answer is inventory and triage. Once the attacker obtained decrypted environment variables, they would have needed to sort through them — identifying which keys were live, which services they accessed, and which ones contained wallet private keys worth draining. A standard sweeper script can run in minutes once it has a target list, but building that target list from thousands of environment variables takes time.

The 12-hour gap also means Railway had most of the day to detect the crypto drain before it went public. The company has not said when it first became aware of cryptocurrency losses. Railway CEO Jake Cooper (who goes by Postiz on X) was discussing notifications from Stripe and Ant regarding compromised credentials at 21:11 (UTC), 40 minutes before the public disclosure.

Same day, same target, different breach

The Railway breach happened on the exact same day as the LiteLLM supply chain attack (October 21), in which a poisoned version 1.107.0 was pushed to PyPI and Docker with a credential stealer that grabbed browser passwords, cloud credentials, and AI tool API keys. Railway has said there's no evidence the two incidents are connected. But both targeted the same asset class — AI inference provider credentials — and Railway explicitly framed its breach as part of "a series of attacks" aimed at AI inference providers.

The pattern is becoming hard to ignore. In the past week alone: LiteLLM's release pipeline was compromised through stolen GitHub OAuth tokens, Railway's environment variable store was breached, and OpenCode disclosed that 1.4% of its Console users had their OpenAI/Anthropic/Google API keys exposed in what the company called a "large scale distillation attack." Attackers have figured out that the most efficient way to steal AI compute isn't to hack OpenAI or Anthropic directly — it's to hack the middleware and hosting layers that aggregate thousands of API keys in one place.

Why it matters

For AI builders, this is a structural wake-up call. Environment variables are the universal secrets store for every modern application. Every Railway user stores OpenAI keys, Anthropic keys, Stripe keys, database passwords, and Redis credentials there. If an attacker can decrypt those variables, they get a one-stop shop for credential theft.

The $371,000 in crypto losses is almost certainly the tip of the iceberg. Wallet private keys are easy to monetize immediately — sweep and transfer. API keys to AI providers are harder to cash out directly but can be used for "LLMjacking" — running inference on someone else's bill, as Wiz Research documented in the LiteLLM aftermath, where stolen AWS credentials were used to list available Amazon Bedrock models within 4.5 hours of the breach. Stripe keys can be used for fraudulent payouts. Database passwords can exfiltrate customer data. The full damage may take weeks to assess.

Railway's decision to pause all builds for over 19 hours — including for Enterprise customers — was the right call operationally but devastating for a platform whose entire value proposition is "deploy in seconds." Users couldn't roll out new versions, couldn't rotate keys through redeployment, and were left staring at dashboards they couldn't use. On October 22, Railway confirmed it had reset all storage bucket credentials and GitHub tokens held for customer accounts, meaning the old credentials no longer work and affected customers must redeploy with replacements.

The critical lens

A few things don't add up yet. Railway said the attacker "may have accessed encrypted environment variables" — but if the variables were encrypted at rest, how did the attacker get decrypted contents? The implication is that the attacker also obtained the decryption keys or found a path through the decryption service. Railway hasn't explained the encryption architecture or the specific attack vector.

The "subset of users" framing is also vague. How many users? What percentage? Railway has promised to email affected customers directly, but as of October 22, no public count has been given. For a platform with tens of thousands of projects, even 1% is hundreds of teams.

And the timing — 12 hours between build pause and first crypto theft, 2 hours between first theft and public disclosure — deserves a full timeline from Railway. Did the company know about the crypto drain before going public? If so, why wait? If not, how did it miss $371,000 in on-chain transactions that an independent investigator found within hours?

What to watch

• Whether Railway publishes a full root-cause analysis explaining how environment variables were decrypted
• The number of affected customers, when Railway begins sending notification emails
• Whether AI inference providers confirm anomalous usage from keys stored on Railway
• Whether the attacker address 0xd9773325282874d18cb83f1fe50f14c39750b2ee launders funds through mixers or cross-chain bridges
• Whether this is confirmed as connected to the LiteLLM attack or part of a broader campaign against AI tooling platforms
• Whether Railway implements environment-variable encryption with customer-managed keys (HSM/KMS integration) as a remediation

If you deploy on Railway, rotate everything. Now.