Railway: a build flaw let an attacker decrypt customer secrets and run up about $740,000 on stolen AI keys

How it happened

Railway says the attacker exploited a previously unknown vulnerability in its multi-tenant build infrastructure to partially escape filesystem isolation. That gave a credential the build servers use to reach some internal systems, which its internal Temporal instance accepted as a trusted client. The attacker then used an erroneously defined OIDC binding in one of its cloud environments to get a short-lived cloud credential, and a long-lived credential and SSH key to decrypt variables through the key management service.[1] Checked 11 Nov 2026

What was stolen

A copy of Railway's internal monorepo, the stored histories of 353 builds including sealed variables, decrypted environment variables of at most about 100,000 workspaces, and linked-account tokens (GitHub OAuth tokens and bring-your-own AI agent keys) of 1,852 users. Railway says AI provider keys were the main target; other queries also matched cloud, database and payment service credentials. It says forensics did not show access to customer databases and it has no sign that customer repositories were downloaded.[1][3] Checked 11 Nov 2026

Who was impacted

Railway customers: at most 1.85% of workspaces, about 100,000, could have had environment variables decrypted; Railway calls this an upper bound. 1,852 users had linked-account tokens exposed, all reset. Railway says it found no logins to Railway accounts with credentials taken in the incident.[1][3] Checked 11 Nov 2026

Threat actor

Not attributed

Timeline

1. 18 Oct 2026Railway says the attacker starts creating dummy accounts; early attempts fail. [1]
2. 20 Oct 2026At 06:50 UTC the attacker starts probing the build infrastructure, and at 07:28 UTC exploits an unknown vulnerability to partially escape filesystem isolation. Railway's on-call team is paged at 13:58 UTC. Builds are halted at 17:03 UTC and the build credential is replaced at 17:28 UTC. [1]
3. 21 Oct 2026At 03:26 UTC the attacker gets a short-lived cloud credential through a misdefined OIDC binding, then decrypts variables through the key management service between 04:42 and 07:15 UTC. Railway disables cloud credentials and the decryption service at 07:14 UTC and says the attacker is fully evicted by 09:24 UTC. AI providers receive lists of potentially exposed keys at 09:25 UTC, and all user sessions and tokens are invalidated at 20:19 UTC. [1]
4. 22 Oct 2026Railway publishes a preliminary report: at most 1.85% of workspaces, about 100,000, had some environment variables potentially compromised. It tells customers to rotate sensitive variables and remove public network access to databases, and says the attacker had access to abliterated models with no safeguards. Builds are restored over the day, starting with Enterprise customers. [2]
5. 10 Nov 2026Railway publishes its full incident report. It estimates unauthorised spend on the stolen keys at about $740,000, says it is working with providers on refunds and will cover what they will not, and says each build now runs in its own ephemeral virtual machine. It cites Wiz's "Black October" research on attacks against platforms holding AI keys but does not itself attribute the incident to the same operator. [1][3]