Railway Breach: Stolen AI API Keys and $740,000 in Charges

Railway has published its full incident report on the October attack that hit its platform, and the headline number is uncomfortable reading for anyone who stores API keys in a hosting platform: the stolen credentials were AI provider keys, and they were used to run up an estimated $740,000 in unauthorized AI usage.

The report is dated November 10, 2026 and is the company’s own account of what happened. Secondary coverage from BleepingComputer and The Hacker News matches it on the core figures. Below is what Railway actually confirmed, what it did not, and the checks worth making if your projects ran on the platform.

What Railway says happened

Railway says its engineers detected unauthorized access on the afternoon of October 20, starting with a previously unknown vulnerability in its build infrastructure. The attacker used that entry point to partly escape filesystem isolation, obtain an internal credential, and read stored build histories — including copies of Railway’s internal source code. A second issue, described as an improperly configured trust relationship, then gave the attacker access to credentials used to decrypt customer environment variables.

Railway describes the following roughly 26 hours as a race, with its team hardening routes in parallel while the attacker probed others. The company halted builds twice, rotated internal credentials, and invalidated every user session and token on October 21. It says the attacker was fully evicted by 09:24 UTC on October 21 and that builds were restored for all plans by late on October 22.

What was actually taken

Environment variables for at most 1.85% of workspaces, which Railway puts at roughly 100,000 workspaces. The company is explicit that this is an upper bound: its logs show which environments were exposed, not which individual variables.
Linked-account tokens for 1,852 users, including GitHub OAuth tokens and bring-your-own-key agent keys. Railway says all of these were reset and each affected user was notified.
Build histories for 353 builds, including the variables and secrets passed to those builds.

Railway’s forensics found no access to customer databases and no indication that customer code repositories were downloaded. It also says it found no logins to customer accounts using stolen credentials. Data the attacker copied but never decrypted can no longer be decrypted, because the credential involved has been disabled.

The $740,000 bill, and who pays it

Railway says the attacker specifically searched for AI provider credentials, apparently to resell them for use in model distillation, and that the stolen keys produced about $740,000 in unauthorized AI usage. The company has said it will cover charges that the AI providers decline to refund.

Refund handling differs by provider in Railway’s report: AWS Bedrock and Google Gemini are covered by existing fraud policies, OpenAI and one further provider review claims case by case, Anthropic talks were still underway with Railway covering costs in the meantime, and OpenRouter’s terms are no-refund, so Railway covers those costs itself. If you were affected, file with the AI provider first and pass the case reference to Railway support.

What to check now

Rotate, don’t just revoke. A rotated key with the old one deleted closes the exposure; a revoked key you forget to replace takes production down quietly.
Set spend caps at the AI provider, not just in your app. The provider’s hard limit is the only ceiling that applies when a key leaks and your own code never sees the request.
Scope keys per environment. A staging key that can only reach a cheap model limits the blast radius of exactly this kind of incident.
Watch billing anomalies. Unusual token volume on a project that should be idle is the fastest available signal.

Our practical AI risk checklist for small teams covers key handling and spend limits in more detail.

What we did not do

We did not speak to Railway, test its infrastructure, or review any customer’s account. This article restates the company’s published report and two independent write-ups. No attacker group has been named by Railway, and none is named here.