senn-techRailway breach: what the report proves and which secrets operators should rotate
On 22 October 2026 Railway published a preliminary report on a break-in to its own infrastructure. According to Railway, an attacker first pulled encrypted secrets, then reached CI credentials, used them to decrypt artifacts and afterwards decrypted a subset of the environment variables. Railway says at most 1.85 percent of all workspaces were affected, about 100,000.
A break-in at a hosting platform means that credentials stored there as environment variables count as known to the attacker. That covers database passwords, tokens for Git providers and API keys for AI services. The operator rotates them before the cause is understood. With nested encryption it is often impossible to tell which variable actually leaked. That is the case here.
The sequence according to the report
All times UTC, all details from Railway itself. There is no independent verification yet.
| Time | Event according to Railway |
|---|---|
| 20 Oct, 13:58 | Monitoring reports elevated latency, on-call starts investigating |
| 20 Oct, 14:03 to 16:51 | Classified as attempted privilege escalation in the build infrastructure, builds are halted |
| 20 Oct, 19:53 | Evidence that the attacker can escalate in parallel across several parts of the system |
| 21 Oct, 04:24 to 05:23 | Attacker pulls secrets in encrypted form but cannot decrypt them yet |
| 21 Oct, 05:27 to 07:25 | Attacker reaches CI credentials and decrypts artifacts holding further API access |
| 21 Oct, 07:25 to 09:18 | Database trace of an unauthorized query of encrypted variables, a subset decrypted |
| 21 Oct, 09:25 | Railway notifies vendors such as GitHub, Anthropic and OpenAI and asks them to revoke keys |
| 22 Oct, 03:32 | Railway confirms the attacker no longer has access to internal systems |
Source: Railway, preliminary report of 22 Oct 2026, as published there. The report states that the investigation is ongoing and that details of the nature and extent of the exploitation are withheld for now.
Railway's account and what stays open
Everything that follows is Railway's own account. According to it, the path ran through the build infrastructure: the attacker pulled encrypted secrets, then reached CI credentials and decrypted artifacts, later a subset of the variables. Railway also says existing services kept running and that the attacker did not log into customer accounts.
Only Railway claims the attacker's motive and equipment. Railway writes that the attacker searched for API keys of AI companies in order to train its own models on their answers. It adds that the attacker had models stripped of refusal logic ("abliterated models") and a lot of compute. That comes from Railway's reading of the attacker's logs. A web search on 9 November 2026 found no second source.
One open question follows from the report: why could a CI environment hold material that decrypts customer data? The report does not answer it. As a countermeasure Railway names the move from multi-tenant to single-tenant builders, which had been planned for the following week and was brought forward.
What applies to us
Railway does not appear in our infrastructure inventory (as of 9 Nov 2026). So we have no known deployment there; an inventory does not prove that no test project exists anywhere. The questions behind the incident apply to any setup with CI and stored secrets:
- Which credentials sit in the build environment, and can they decrypt production secrets?
- Do
.envfiles and keys stay out of Git? That is our rule. - How long does it take to replace every key of a service? Whoever has never practised it finds out during the incident.
How such a rotation runs after a compromised package is covered in LiteLLM 1.107.0: malicious code and key replacement. More posts on this topic are collected in the hub Security and data protection. If you want your secrets and build pipeline reviewed, see Services.
What Railway customers should do now
The company recommends four steps: remove public network access from databases, rotate all sensitive variables, check GitHub audit logs and installed apps, and check the logs of the container registry. Do not read too much into revocation mails from GitHub, Anthropic, OpenAI or Stripe: Railway reported all stored keys to some vendors as a precaution, so a revocation mail does not prove a leak.
In its update of 26 October, in the same report, Railway said all existing users were fully served again, while new sign-ups stayed paused. Railway does not refund costs from misused AI keys. Affected users contact the AI providers and send evidence on through Railway's support portal.
Further reading
- Railway, preliminary report of 22 Oct 2026: blog.railway.com
- Railway, first notice of 21 Oct 2026: blog.railway.com
- Railway changelog on the incident: railway.com/changelog
Do I need to rotate keys if I used Railway?+
Yes, if the account existed before 21 October 2026 and stored variables there. Railway recommends that every customer who signed up before that date rotates all stored keys, even without a direct notification. By its own account Railway cannot tell which single variable was decrypted, because the keys are stored wrapped in several layers.
Were my running services offline?+
According to Railway's report, no. Existing deployments kept running. New builds and deployments were paused, and the dashboard, API and CLI were unavailable at times. Railway says commits pushed during the pause were not deployed and have to be redeployed.
Does Railway refund costs from stolen AI keys?+
Not according to the update of 26 October in the same report. Railway points to the AI providers and offers to pass evidence on through its support portal. Affected users should collect timestamps and the providers' billing items.