Our October 22 digest noted Railway's first disclosure: an unauthorised party may have decrypted customer environment variables. Late on October 22, 2026 (UTC), Railway published a preliminary incident report with a timeline, an impact estimate and a motive. The forensic investigation is still running, and Railway says several details are being withheld for now.
The timeline
Monitoring paged on-call engineers at 13:58 UTC on October 20 for elevated latency. Within three hours Railway had identified "potential privilege escalation in our build infrastructure", halted build pipelines and declared an incident. By 18:05 engineers believed the exploit was remediated and could not reproduce it. At 19:53 "additional evidence was identified that the attacker could escalate their access, at higher scale, across multiple parts of the Railway system, in-parallel." Overnight, "Subsequent routes of access were identified" and builds were halted again.
The decisive steps came on October 21. Between 04:24 and 05:23 UTC Railway found the attacker had pulled secrets in encrypted form but could not yet decrypt them. Between 05:27 and 07:25, "the attacker accessed credentials to access our CI environment where the attacker was able to decrypt artifacts that held additional API access." By 09:18 database logs showed "an unauthorized query of encrypted environment variables, of which a subset were decrypted utilizing a combination of the compromised credentials." Attacker payload logs then showed "the specific API key names they were searching for", and at 09:25 Railway asked vendors to revoke keys. From 03:32 UTC on October 22 it began reinitialising internal systems "with the minimal required dependencies, new credentials, and additional hardening", and it reported full API restoration between 17:00 and 22:49 UTC that day.
Scale and motive
Railway says "at most 1.85% of all workspaces had some environment variables potentially compromised. This represents, numerically, about 100,000 workspaces." Because envelope encryption meant the query alone "cannot identify specifically which keys" were affected, Railway gave vendors all keys it held for some services, so provider-driven resets reached more than 100,000 users. It is also contacting a high-risk group larger than the 1.85%.
On motive the report is direct: "Early investigations tell us this attack was attempting to obtain AI provider API keys to perform distillation attacks." The attacker prioritised workspaces with very many variables and those holding many AI vendor keys. Railway adds that "the malicious actor had access to abliterated models and substantial compute resources", which it believes enabled the exploits. It has not said how it knows this. Existing deployments stayed online throughout; Railway has rolled all keys twice, reset its GitHub App installations, rebuilt tooling from validated source and moved builders to a single-tenant environment. It is "not ruling out" access to user source code.
Why this is an AI story
This is the third incident in a week where AI credentials were the prize. OpenCode said on October 17 that a "large scale distillation attack" hit users who had linked provider keys, and LiteLLM's compromised releases harvested tokens. A provider key is now directly convertible into model outputs, which can be resold or used to train a copy, so platforms that hold many such keys concentrate value the way payment processors do.
What remains uncertain. The initial access vector, the exploit details, which variables were decrypted per workspace, whether source code was read, and the attacker's identity are all unknown. The claim about abliterated models is Railway's inference and is unexplained.
Analysis: Envelope encryption held until the attacker reached CI, where decryption material lived next to deployment credentials. That is the transferable lesson: if your CI can decrypt production secrets, CI is your secret store, and it needs the same isolation. For teams that use AI APIs, three controls cut the payoff from a breach like this. Use per-service, per-environment provider keys so one leak does not expose everything. Set spend caps and usage alerts at the provider, because distillation shows up as volume. And prefer short-lived credentials (workload identity or brokered tokens) over static keys sitting in a platform's variable store. If you were on Railway before October 21, rotate everything, not just AI keys.
Sources and evidence
Railway's October 22 preliminary report says an attacker escalated from build infrastructure to CI credentials, used them to decrypt a subset of envelope-encrypted customer environment variables affecting at most 1.85% of workspaces (about 100,000), and searched for AI provider API keys to perform distillation; the access vector is still unknown, so platforms should treat CI decryption access as part of the secret store and AI users should scope, cap and rotate provider keys.