Railway breach: stolen AI keys cost an estimated $740,000, up to 100,000 workspaces

Railway, the cloud platform that hosts apps for developers, says attackers who broke into its build system on 20 October 2026 went on to decrypt stored customer secrets, hunting mainly for AI provider API keys, and that the stolen keys produced an estimated $740,000 in unauthorised AI usage. In an incident report published on 10 November, the company says it will pay for any charges that AI providers refuse to refund. If you stored AI keys, cloud keys or tokens in Railway variables before 21 October, rotate them with the issuing provider.

Key points

• Railway says an attacker escaped build isolation on 20 October 2026, reached internal systems, and between 04:07 and 07:15 UTC on 21 October queried and decrypted customer variables; the attacker was fully removed at 09:24 UTC on 21 October.
• At most 1.85% of workspaces, about 100,000, may have had variables decrypted. Railway calls this an upper bound, because its logs show which environments were exposed and not which variables were read.
• Linked-account tokens of 1,852 users, including GitHub OAuth tokens and bring-your-own-key agent keys, were decrypted; Railway reset them and notified the users, and found no logins using stolen credentials.
• The stolen AI provider keys were used for an estimated $740,000 in unauthorised spending, and Railway says it will cover what providers do not refund.
• Railway found no evidence that customer databases or code repositories were accessed.

What to do

Railway's report gives no full checklist, but these are the actions it and its guides point to:

1. Rotate sensitive variables with the issuing provider. Any AI, cloud, database or payment key you stored in Railway before 21 October should be revoked or rotated at the provider, not only changed in Railway. Railway reports the attacker's database query also matched cloud, database and payment-service credentials.
2. Check AI provider usage and bills. Look for spend you did not make. Railway asks affected customers to report unauthorised charges through the form linked in its report; filing a report does not revoke a key.
3. Claim refunds from the provider where required. AWS Bedrock and Google Gemini apply their fraud refund policies; for OpenAI and a provider the report lists as SpaceXSI, you open a case with the provider and send the case ID to Railway support, and refunds are reviewed case by case. Anthropic talks were ongoing at the time of the report, and Railway says it covers costs from breached Anthropic keys in the meantime. OpenRouter keeps its no-refund terms, so Railway covers those costs.
4. Recover access. Railway invalidated all user sessions, API tokens and project tokens. Its advice is to redeploy your latest commit, reconnect GitHub, and recreate CLI and CI credentials. Review your GitHub audit log and the list of apps that can access your account, and check registry audit logs such as Docker Hub.
5. Close public database access. Railway recommends removing public network access to databases.

For a general method, see our guide on how to rotate leaked environment variables and API keys after a platform breach.

What happened

Railway first disclosed the incident on 22 October with a preliminary report and told customers to rotate secrets. Its full incident report, published on 10 November, revises some of the earlier timings. According to the report, the attacker began creating dummy accounts on 18 October, and early attempts failed. At 06:50 UTC on 20 October the attacker probed the build infrastructure, and at 07:28 UTC exploited a previously unknown flaw in the multi-tenant build system to partly escape filesystem isolation, read files on the host virtual machine and obtain a build credential.

That credential was more powerful than it should have been. It could call the APIs of Temporal, the workflow system Railway uses internally, which exposed stored build histories and build variables, and it could fetch repository snapshots, giving the attacker a copy of Railway's internal monorepo. Between 13:50 and 15:30 UTC the attacker read the stored histories of 353 builds. An alert about unusual registry API calls paged an on-call engineer at 13:58, about six and a half hours after the escape. Railway halted builds at 17:03 and replaced the build credential at 17:28.

The attacker was not finished. Using what it learned from the source code, it found a misconfigured OIDC trust binding in a cloud environment and, at 03:26 UTC on 21 October, obtained short-lived production cloud credentials. Those led to a credential that could read the encrypted variables database and to an SSH key for an orchestration machine, which held a long-lived credential able to decrypt customer variables. Between 04:07 and 05:21 UTC the attacker queried variables, prioritising names that looked like AI provider keys, and decrypted some of them in two windows (04:42 to 05:14 and 06:36 to 07:15). Railway disabled active cloud credentials and the decryption service at 07:14 and evicted the attacker at 09:24 UTC.

BleepingComputer, summarising the report, describes a roughly 26-hour contest in which Railway's engineers and attackers using AI-powered agents probed and hardened systems in parallel. It quotes Railway: "This was not a single breach followed by a single fix."

Background

Platforms like Railway store customers' environment variables encrypted, so that apps can read their database URLs and API keys at deploy time. That makes the variables store a concentrated prize: whoever can decrypt it gets keys for many unrelated services at once. In October 2026, according to The Hacker News's summary of Wiz's "Black October" analysis, at least nine AI developer platforms disclosed breaches, among them Northflank, OpenCode, Warp and Lightning AI, and attackers consistently hunted for stored environment variables, especially AI access keys. Wiz says no single flaw links the incidents.

Why AI keys? Railway says it believes the stolen credentials were used by services that resell or relay access to AI providers, or for model distillation. It has not confirmed whether the attacker ran those services and has not named the attacker. An AI key is directly spendable, unlike many stolen secrets, which is why the costs landed so fast. Our earlier report on CrowdStrike's findings about the Vapor Panda group shows the same interest in AI credentials.

The numbers

type: bar
title: Railway incident, key figures from the company's report
unit: count
source: Railway incident report, 10 November 2026
Users with linked-account tokens decrypted | 1852
Builds whose stored histories were read | 353

Two numbers deserve caution. The 100,000 workspaces figure is Railway's maximum, and the $740,000 is an estimate: The Hacker News notes the report does not explain how it was estimated or what period it covers.

What it means

For developers who deploy on managed platforms, the lesson is the one that platform incidents keep repeating: a secret stored in a hosting dashboard is only as safe as the platform's weakest internal credential. Railway's chain depended on a build credential with too much reach, an OIDC binding that was too permissive, and long-lived decryption credentials sitting on a machine. Its stated remediation addresses each: every build now runs in its own short-lived virtual machine with a credential limited to pushing one image, access to cloud environments uses short-lived credentials where possible, and all encrypt and decrypt operations are audit-logged.

For AI API users, the practical fixes are on the provider side: per-project keys, spending limits and usage alerts, which turn a stolen key into a capped loss. That Railway itself is absorbing refunds for providers that decline is unusual; customers of other platforms may not get that.

What we don't know yet

• How the $740,000 estimate was calculated and what period it covers, and whether there is a claim cap or deadline (The Hacker News raises both questions).
• Whether customers must pay disputed charges while claims are reviewed.
• Who the attacker is. Railway has filed a complaint with the FBI's IC3 and is working with an outside forensics firm, and says it will publish indicators of compromise once law enforcement agrees.
• The unknown vulnerability in the build isolation: Railway says all the weaknesses used are closed but describes this one only as previously unknown.
• Sources disagree on one detail. The Hacker News says Railway sent reset requests to more than 100,000 users; the incident report as we read it does not state that, so we leave the figure out.

What to watch next

• Railway's promised indicators of compromise and any update on provider refunds, especially Anthropic's.
• Further disclosures from the platforms Wiz groups under "Black October".
• Whether AI providers add default spending caps for keys, which none of the sources promise.

Sources

• Railway: Incident report, October security incident (primary)
• BleepingComputer: Railway breach leads to $740,000 in fraudulent AI charges
• The Hacker News: Railway says stolen customer AI keys led to $740,000 in estimated unauthorized usage charges