The headline numbers, and what they don't say
Some of the figures are easy to misread.
- $740,000 is an estimate. In its own words, Railway says unauthorized spend on the stolen keys was estimated to reach ~$740,000. The company says it is working with providers on refunds and backstopping charges from its own balances for providers that decline.
- About 100,000 workspaces (1.85%) is an upper bound. Railway says attackers reached its internal source code and decrypted environment variables for at most 1.85% of workspaces. Its logs identify environments, not individual variables, so the figure is a ceiling. It is not a count of confirmed thefts.
- 1,852 users had linked-account tokens exposed. The decrypted data included BYOK agent keys and GitHub OAuth tokens. Railway says it reset every token, notified each user, and found no Railway logins using credentials taken in the incident.
Railway also says it found no evidence that attackers downloaded customer Git repositories or accessed customer databases. Those are the company's own forensic findings, not independent verification.
How the attack unfolded
Railway's timeline describes a chain of two separate weaknesses. All times are UTC.
- October 18: Attacker-controlled dummy accounts began signing up and probing. Railway says these early attempts failed.
- October 20, 07:28: The attacker exploited a previously unknown flaw in the build infrastructure. It let them partly escape filesystem isolation on a shared build VM and read some host files. That yielded a credential the build servers use to authenticate to some internal systems.
- Why that credential mattered: It was meant only for build work such as pushing images. But Railway's internal Temporal task system accepted it as a trusted client. Through that, the attacker read stored build histories, including some variables, and retrieved a copy of Railway's internal monorepo from cached repository snapshots.
- October 20, 13:58: An alert on anomalous calls to the build-artifact registry paged an on-call engineer. Railway says 353 build histories were read between 13:50 and 15:30.
- October 21, 03:26: Using knowledge from the stolen code, the attacker found an incorrect OpenID Connect (OIDC) trust configuration that exposed a short-lived cloud credential.
- Lateral movement: That credential retrieved internal credentials, including an SSH key. The attacker used the key to reach a fleet-orchestration machine. A file on that machine held a longer-lived credential for decrypting environment variables.
- October 21, 04:07–05:21: The attacker pulled encrypted variable envelopes from the production database. Logs show queries that matched variable names against attacker-supplied regular expressions to prioritize AI provider keys. They also targeted customers with many variables.
- October 21, 04:42–07:15: The attacker decrypted some of those variables in two windows. Railway disabled credentials at 07:14 and shut down builds at 07:22.
Railway says the attacker was fully evicted by 09:24 and had no customer-data access after 09:25 on October 21. The company notes it only established that later in the day, after full validation.
The report corrects some details from Railway's preliminary write-up. The attacker's first signups predate the page that opened the timeline. Key decryption also started earlier than first reported.
Why this is a developer-security story
Encryption helped, but only partly
Railway uses envelope encryption. Each environment has its own data-encryption key, protected by a root key in an upstream cloud key-management service, and the root key can't leave that service. That design limited the blast radius to a subset of environments. It did not stop an attacker who held a credential allowed to ask the key service to decrypt. In general terms, envelope encryption protects stored data. It does much less once an attacker can act as an authorized caller.
Trust relationships were the weak link
Two flaws carried the attack. One was a credential accepted by a system it was never meant to reach. The other was a misconfigured OIDC binding in the CI/CD path. Neither is exotic. Both are the kind of thing an access review is meant to catch. The stolen source code then made the search for the next gap much faster. Railway says it saw the attacker probing endpoints with no live references in the system anymore, and that is how it realized they had the code.
Agents on offense
Railway describes the fight as a contest of agent speed. It says it faced "abliterated" models, meaning models stripped of safeguards, and a harness similar to one called ARTEX, according to Wiz. Treat that as Railway's characterization. The practical lesson is general: once an attacker has your code, the time between one foothold and the next may be short.
The wider "Black October" pattern
Railway says the attackers were hunting AI credentials, and it believes they were meant for resale or model distillation. That is the company's assessment. It also says it has customer-shared indicators and examples of unauthorized requests consistent with keys passing through relay or reseller services. However, Railway says it has not established whether the original attacker ran those services.
Security firm Wiz has grouped the breach with a run of incidents it calls "Black October." Wiz lists at least nine AI developer platforms that disclosed incidents during the month, including Fireworks AI, Lightning AI, OpenCode, Railway, Warp and Northflank. Wiz says that all public reports show targeted hunting of stored environment variables. It adds that the growing LLMjacking market makes stolen AI access easy to monetize. Neither Wiz nor Railway claims one actor was behind every incident.
What developers should do now
Railway's guidance reflects general good practice for any provider that advises rotation.
- Rotate at the issuer, not just in the platform. Revoke the old key with the AI, cloud, registry or payment provider, then update the variable. Editing a variable in a hosting dashboard does not invalidate the underlying key.
- Treat anything stored before October 21 as potentially exposed, including API keys, private registry credentials and tokens for cloud, database and payment services.
- Check provider usage dashboards for charges you didn't make. Railway asks customers to report them.
- Review GitHub audit logs and installed OAuth apps if you linked GitHub, since OAuth tokens for some users were exposed.
- Close public database access where possible, and review service logs for unusual activity.
- Scope keys tightly. Spending caps, per-project keys and narrow permissions limit the damage from a leaked secret.
Service impact and fixes
Railway paused builds twice. It restored them in stages on October 22: Enterprise first, then Pro, Hobby and finally Free and Trial at 22:49. It also invalidated all user sessions and tokens on October 21. Existing deployments kept running, but customers who revoked a credential couldn't redeploy until builds returned. Railway acknowledges that some customers experienced downtime because of this. It also paused new signups from October 22 until November 2.
Railway says it has since:
- accelerated a planned move to per-build ephemeral virtual machines, layered on top of the old isolation;
- limited build credentials to pushing one specific OCI image;
- rebuilt its CI systems with 2FA and biometric approval in critical areas, plus logging and SIEM alerting;
- moved to short-lived, narrowly scoped internal credentials;
- centrally logged all encrypt and decrypt operations, so only the secrets service can reach keys that decrypt data-encryption keys.
These are reported measures, not a guarantee against future attacks.
Bottom line
Railway's report is more detailed than most breach disclosures. Two modest-looking flaws were enough to turn a build sandbox into a credential vault. The $740,000 figure will grow or shrink as providers settle, and the 100,000-workspace number is a ceiling. The lesson for anyone deploying through a hosted platform is to keep secrets short-lived and scoped, and to rotate them quickly when a provider says to.