Preliminary report: Oct 21st security incident
B · Useful, limited Railway's own preliminary incident report gives a detailed timeline and impact range, but the exploit is undisclosed, the root cause is not final and the claim about attacker tooling is unsupported.
Summary based on the full text·Original: about 7 minutes to read
In short
A 22 October 2026 preliminary report by Jacob Cooper and Angelo Saraceno of Railway, a cloud deployment platform, on a targeted campaign that escalated privileges through its build infrastructure, reached its CI environment and decrypted a subset of customers' stored environment variables. Railway says the attacker was hunting AI provider API keys to run distillation attacks, and believes the attacker had access to "abliterated models" (models with safety refusals removed) and substantial compute. Running customer services stayed up; builds, dashboard, API and CLI were disrupted.
Key numbers
- at most 1.85%share of Railway workspaces with environment variables potentially compromised
- about 100,000workspaces that 1.85% represents
- October 20th 13:58 UTC to October 22nd 03:32 UTCattack window, ending when Railway confirmed the attacker had no internal access
- 09:25time on 21 October when Railway asked vendors to revoke potentially exposed keys
As reported by the source.
English·Web page·opens blog.railway.com
What it reports
- Timeline: abnormal latency paged on-call at 13:58 UTC on 20 October; privilege escalation in build infrastructure identified and builds halted; a first remediation was followed at 19:53 by evidence the attacker could escalate further in parallel.
- 21 October: attacker pulled encrypted secrets, then used CI credentials to decrypt artefacts with further API access; database evidence showed an unauthorised query of encrypted environment variables, a subset decrypted. Attacker payload logs named the specific API keys sought.
- At 09:25 UTC on 21 October Railway asked vendors (GitHub, GitLab, Anthropic, OpenAI, OpenRouter, Stripe and others) to revoke keys; for some it sent every key stored on the platform.
- Impact: at most 1.85% of workspaces, about 100,000, had variables potentially compromised; envelope encryption means Railway cannot tell exactly which keys were decrypted. High-risk groups: workspaces with many variables or many AI vendor keys.
- User accounts were not accessed; access to source code is not yet ruled out.
- Actions: all keys rolled twice, tooling rebuilt from validated source, builder infrastructure moved early from multi-tenant to single-tenant, mass permission revocation added, external forensics engaged.
- Advice: rotate variables stored before 21 October, remove public network access to databases, review GitHub and registry audit logs.
How they got it
The company's own forensics during and after the incident, with external responders engaged. Specific exploits and scale details are withheld pending the final report.
Limits
- Preliminary: root cause, exploit details and final impact are not given.
- The "abliterated models" claim is stated as initial belief with no evidence shown.
- Customers were told to rotate keys only after the attacker was ejected; the trade-off is explained but notification came late on 21 October.
- Self-reported by the affected company.
Why it matters for companies
AI provider keys have become a target in their own right, worth a sustained campaign against a hosting platform. Any company storing model API keys in a PaaS should treat them like payment credentials: scope them, set spend limits, rotate them and monitor usage for anomalies. The incident also shows the cost of multi-tenant build systems; Railway moved to single-tenant builders a week early because of it. Check where your build pipeline's credentials live.
Summary based on the full text. Read the original for the full argument and data.Read the original on blog.railway.com
- Tags
- AI security, Supply chain