Railway Puts Exposed Variables at 1.85% of Workspaces, About 100,000, After a Build-Infrastructure Escalation

Railway says an attacker who escalated privileges in its build infrastructure on Oct. 20 decrypted environment variables for at most 1.85% of workspaces, about 100,000, and was hunting AI provider API keys for what the company calls distillation attacks. The platform's preliminary report, by Jacob Cooper and Angelo Saraceno, dates the attack window from Oct. 20 at 13:58 UTC to Oct. 22 at 03:32 UTC.

Railway's first disclosure went out on Oct. 21 and described only "anomalous activity involving systems that store customer environment variables". It links a longer incident report dated Nov. 10, which this article did not read; everything below is from the preliminary report and its updates through Oct. 26.

How the intrusion progressed

The report does not name the entry point. It describes an attempted privilege escalation by an external party in build infrastructure, found between 14:03 and 16:51 UTC on Oct. 20, and later says "subsequent routes of access were identified." Railway has withheld exploit detail, citing the open investigation.

Time (UTC)	What Railway reports
Oct 20, 13:58	On-call paged for abnormal activity
Oct 20, 19:53	Evidence the attacker could escalate at scale in parallel
Oct 21, 04:24	Secrets pulled in encrypted form, not yet decrypted
Oct 21, 05:27	Attacker reaches CI credentials and decrypts artifacts
Oct 21, 07:25	Unauthorized query of encrypted variables; a subset decrypted
Oct 21, 09:25	Vendors told to revoke keys

Railway's own timeline conflicts with its FAQ on the last row: the table says 09:25 UTC and the FAQ says 09:35 UTC. The report also says the attacker confirmed absent from internal systems between 03:32 and 06:29 UTC on Oct. 22, after which systems were reinitialised with new credentials.

What was and was not taken

Railway says the attacker queried encrypted environment variables and decrypted a subset using compromised credentials, and that the query alone cannot show which keys in a given project were affected. It says "The attacker did not access Railway user accounts as part of this incident," while source code access is not ruled out. Existing deployments stayed online.

The attacker's payloads, read by staff on Oct. 21 between 09:18 and 09:25 UTC, showed which API key names were being searched for. Railway says targeting favoured workspaces with very large numbers of variables and environments holding many AI vendor keys.

Two numbers that look alike

1. Workspaces potentially exposed (at most)100K items
2. Provider reset requests (more than)100K items

Source: Railway preliminary report, accessed 2026-11-12

Railway puts the exposed share at no more than 1.85%, about 100,000 workspaces, and says it sent more than 100,000 reset requests to providers. Those are different quantities. The requests cover every key Railway stored, because it notified providers about all of them out of caution, so the second figure is a floor on caution, not a count of stolen keys. By dividing, 100,000 at 1.85% implies roughly 5.4 million workspaces; the report separately gives about 5 million existing users. BleepingComputer's earlier report cites about 4.8 million users and more than 16 million services.

Railway's changes and what customers do

Railway rotated all keys, rolled credentials for every storage bucket on the platform, moved builders to a single-tenant environment earlier than planned, rebuilt tooling from validated source, rolled all GitHub App installations and engaged an external forensics firm.

Customers should revoke and reapply sensitive variables stored before Oct. 21, remove public network access to databases, and check GitHub and registry audit logs. Railway says it cannot refund spend made with compromised keys, though it will escalate requests that carry timestamps and proof of fraud. It sits among nine October incidents in Wiz's count, and the same stored-secret pattern ended the Chainstack intrusion in production. GitBook's post-mortem describes a similar route from a staff session to production.