Railway Says Attacker Decrypted Environment Variables for Up to 1.85% of Workspaces

An attacker who got into Railway's build infrastructure on October 20 read encrypted environment variables belonging to up to 1.85% of all workspaces (about 100,000, by Railway's own estimate) and decrypted some of them. The hosting platform's preliminary report, dated October 22, says the target was API keys for AI providers.

The practical instruction is the same for every Railway customer: rotate secrets stored as environment variables, starting with AI provider keys, database credentials and registry logins.

What Railway says was taken, and what it has not ruled out

The report, written by Jacob Cooper and Angelo Saraceno, describes "unauthorized access to a subset of internal Railway systems". Three data classes are named: encrypted environment variables for a subset of workspaces (some decrypted), CI environment artifacts that held further API access, and possibly user source code, which Railway says it has not ruled out pending a final report.

User accounts were not accessed and running services stayed online. BleepingComputer puts Railway at about 4.8 million users and more than 16 million hosted services, so a 1.85% slice is a large absolute number of projects even though most customers are untouched.

The report gives no root cause. It describes a sustained, targeted campaign that began with an attempted privilege escalation in build infrastructure, and defers forensics to a final report from an outside firm. Attribution is absent.

Timeline, October 20 to 22 (UTC)

When	What the report says
Oct 20, 13:58	Attack window begins; on-call engineers paged for elevated latency
Oct 20, 17:03	Incident declared on the status page
Oct 21, 04:24	Secrets pulled in encrypted form; the attacker could not yet decrypt them
Oct 21, 05:27	Attacker obtains CI credentials and decrypts artifacts with more API access
Oct 21, 07:25	Database evidence shows queries of encrypted environment variables; a subset decrypted
Oct 22, 03:32	Railway confirms the attacker no longer has access to internal systems
Oct 22, 17:00	Full API restoration begins across tiers

The ordering matters. By Railway's own timeline the attacker held decrypted CI artifacts from about 05:27 UTC on October 21, roughly 15 hours before the 20:19 UTC start of session invalidation, disclosure and rotation notices.

Why AI provider keys

Railway said, as BleepingComputer reported, that the intrusion was part of a series of attacks aimed at AI inference providers, and it notified those providers directly so they could revoke keys. Its report says the attacker was apparently pursuing distillation, that is, harvesting model outputs at scale with stolen keys.

That motive is Railway's inference from what was targeted, not something an investigator has confirmed. Because Railway notified providers about all stored keys as a precaution, upstream reset requests covered more than 100,000 users, a larger group than the 1.85% whose variables may have been read.

What changed and what to do

Railway says it rotated all internal keys, rolled credentials for every storage bucket and every GitHub App installation, moved builders to single-tenant architecture and added the ability to mass-revoke application permissions. Pro and Enterprise builds came back on October 22 at 06:29 UTC.

Customers should rotate variables that hold secrets, remove public database access, and check GitHub, Docker registry and other audit logs for use of those credentials. The same exposure pattern, many third-party keys in one place, also made the LiteLLM release compromise of October 21 so costly. A disclosure gap of this kind echoes PHP2Shell, where exploitation began four days before patches. Railway says it will contact customers it considers high-risk directly; the final forensic report is the next milestone.