Railway: how a build intrusion reached encrypted secrets

Attack from October 20 to 22, 2026; preliminary report dated October 22. Railway identified unauthorized access to a portion of its internal systems during a campaign that sought, according to its initial investigation, API keys from AI providers. The important detail is not that the platform stored environment variables; all deployment platforms do this. The attacker progressed from possible privilege escalation in the build to internal credentials, then achieved decryption capability of certain variables. Encryption at rest added a barrier, but the attacker crossed it by compromising the credentials needed for decryption.

Reconstruct privilege transitions

Railway dates a first abnormal signal to October 20 at 1:58 p.m. UTC. Its teams suspected an escalation in the build infrastructure and shut down the pipelines to reduce exposure. They then found other access routes and interrupted some services again. On the night of the 21st, the attacker was able to extract secrets in encrypted form; at this point, the report said they could not yet decrypt them. The attacker then obtained credentials from the CI environment to decrypt artifacts containing other API access. Between 7:25 and 9:18 UTC, database traces show an unauthorized query on encrypted variables, part of which was decrypted thanks to the combination of compromised accesses.

This sequence is more precise than a sentence “encryption was useless”. It imposed several additional steps on the attacker. The flaw in separation is that the build environment, CI, and capabilities to reuse or decrypt secrets could ultimately be chained together. The public report does not expose all the details of the initial exploit; Railway speaks of first indications of an escalation of privileges and reserves a more complete disclosure until the end of the investigation.

Measure the scope without overstating the impact

Railway estimates that at most 1.85% of its workspaces, approximately 100,000 workspaces, had potentially compromised variables. This cap is not a number of victims whose every key has been read or used. The report specifies that it cannot identify all the variables actually decrypted from the observed query alone. Key providers have received broader lists for precautionary revocation; receiving a rotation email from one of them therefore does not prove that the customer’s key has been exfiltrated.

Railway says user accounts were not logged in by the attacker in this intrusion. It leaves open, in its preliminary report, the question of possible access to the source code. Deployments already in progress remained online, while new builds and some tools were suspended during the investigation. These distinctions avoid confusing platform interruption, secret leak and code theft.

What an audit should have asked

Preemptive testing of a build platform should look at job isolation, CI agent privileges, credentials that open artifacts, and how a decryption request is authorized. For each key, we follow the complete path: storage, restoration in the job, logs, backups and support access. The criterion to check is: “can a compromised component of the build obtain both the encrypted data and the permissions needed to read it?” “.

Railway says it has rebuilt its tools from verified sources, changed internal keys, accelerated the move to a new generation of isolated builders and asked customers to revoke stored secrets by October 21. The rotation must also happen at the key issuers, then be followed by a review of the accesses carried out during the exposure window. This case shows that encryption at rest is one barrier among several; security depends on isolating decryption capabilities and administrative paths.

Main sources: Preliminary Railway report, first Railway communication.