Railway details how an attacker got from a build server to decrypted customer secrets

What happened

Railway, a platform for deploying apps and databases in the cloud, published a detailed report on 10 November 2026 about an attack that took place on 20 and 21 October 2026. Railway disclosed the incident on 21 October and released a preliminary report a day later, without a root cause. The new report is the first to explain how the attacker got in, what they took and what the stolen keys cost.

Railway says the attacker was mainly after AI provider keys. Their queries against the variables database matched variable names used for AI keys, with a secondary sweep for cloud, database and payment credentials. Railway estimates unauthorised spend at roughly $740,000.

Technical details

Build VM escape. The attacker began creating dummy accounts on 18 October. At 07:28 UTC on 20 October they used what Railway calls a previously unknown vulnerability in its build infrastructure to partially escape filesystem isolation on a build VM. That exposed a credential the build servers use to authenticate to internal systems. Railway doesn't name the flaw and lists no CVE.

Internal systems. With that credential the attacker reached an internal Temporal cluster, which accepted it as a trusted client. From there they read the stored history of 353 builds, including some build variables, and build snapshots gave them a copy of Railway's internal monorepo.

Second path: OIDC. At 03:26 UTC on 21 October they found an erroneously defined OIDC binding in a cloud environment and obtained a short-lived cloud credential. That led to further internal credentials, SSH access to an orchestration machine, and a long-lived credential able to decrypt customer environment variables. Between 04:07 and 05:21 UTC they queried the variables database and decrypted a subset through the key management service.

What the attacker obtained:

• environment variables in at most 1.85% of workspaces (about 100,000) – Railway stresses this is an upper bound because logs identify environments, not individual variables,
• BYOK agent keys and GitHub OAuth tokens for 1,852 users (all reset; Railway found no logins using them),
• the history of 353 builds, including sealed variables.

Forensics did not indicate access to customer databases. The attacker's last access to customer data was at 09:25 UTC on 21 October.

Railway adds that the keys appear to have been sold on through intermediary services for model distillation, and that the attacker used abliterated models. It cites Wiz research on a wave of AI key theft ("Black October") for context but doesn't attribute the attack. We covered similar agent-driven tooling in our piece on ARTEX attacks.

Who is affected

Railway customers, particularly accounts created before 21 October 2026 that stored AI, cloud (AWS, GCP), database, payment or private registry credentials in environment variables. Railway emailed customers it judged to be at high risk. Organisations whose keys were held in Railway by a contractor or developer are affected indirectly.

Railway recorded unauthorised usage at AWS Bedrock, Google Gemini, OpenAI, SpaceXSI, Anthropic and OpenRouter.

How to tell if you were hit

Railway has not published indicators of compromise yet – it is sharing them privately with law enforcement and plans to publish them once cleared. Until then:

• review AI provider billing and usage since 20 October 2026 (unexpected models, volumes, times of day),
• in your cloud accounts (AWS, GCP), look for new access keys, unfamiliar roles and API calls from unknown addresses – Railway published separate guides for both,
• check your GitHub audit log for OAuth app access and installed GitHub Apps, and your registries (Docker Hub) for new logins and pushed images,
• check logs of publicly reachable databases for logins from unknown addresses.

What to do

1. Rotate every variable and key stored in Railway and treat the old values as compromised, even if the provider has already revoked the key. Rotate manually where you can.
2. Rotate private registry credentials and review their audit logs.
3. Remove public network access from databases that don't need it and rotate database passwords (Railway published guides for MySQL, Redis and MongoDB).
4. Report unauthorised charges using the form in Railway's report and to the AI provider.
5. Set spending caps and alerts with AI providers so a stolen key shows up before it does serious damage.
6. If your GitHub email differs from your Railway email and you can't sign in, use email login.

Railway has since rebuilt its build system (each build on a dedicated ephemeral VM with a credential that can only push one image), rebuilt CI, issued a new PKI and root CA, moved to short-lived, narrowly scoped credentials and centrally logs every secret decryption.

Timeline