The report
Railway has reconstructed how an untrusted application build reached cloud credentials and then customer environment variables. Its November 10 incident report estimates approximately $740,000 in unauthorized use of AI provider keys. That figure is an estimated usage cost, not a proven ransom, attacker income or amount charged to every customer.
Two routes through internal authority
The first entry occurred on October 20. Railway says a build escaped part of the filesystem isolation around its build host and read a builder credential. The credential was meant to push completed images, but the self-hosted Temporal service also accepted it as a trusted client. The intruder used that unintended authority to retrieve 353 build histories and a snapshot of Railway’s internal codebase. Railway says it found no evidence that the intruder downloaded customer repository snapshots.
Railway initially closed this route. The copied source nevertheless gave the intruder additional knowledge of old services and cloud deployment paths. The subsequent route abused a CI-to-cloud OIDC trust relationship to obtain a short-lived cloud identity and reach an orchestration system. That system held a credential capable of asking the upstream key-management service to decrypt some customer environment variables. Railway’s logs show searches specifically prioritizing AI provider key names, followed by decryption operations on October 21. The forensic Case distinguishes the two routes and the November 10 incident report preserves the company’s chronology.
What the numbers actually measure
Railway’s upper bound is 1.85% of workspaces, approximately 100,000, whose variables could have been decrypted. It is neither a count of confirmed stolen keys nor 100,000 verified victims. Separately, the company reports linked-account tokens affecting 1,852 users and the 353 accessed build histories. Those are different populations. The incident report attributes the attackers’ speed to modified models and an ARTEX-like harness, but does not establish that the ARTEX framework itself ran the intrusion or provide a complete model-to-command trace.
Railway moved builds toward a dedicated ephemeral VM for each job, restricted builder credentials to image-specific operations, invalidated sessions and engaged AI providers to revoke potentially stolen keys. The lesson of the chronology is precise: isolating customer builds was insufficient while the build identity could query build history, discover internal deployment authority and eventually request decryption. Rotating a Railway credential also cannot invalidate a third-party key already copied by an intruder. That revocation must occur at its issuer.