Railway says some customer environment variables may have been read

On October 21, 2026, Railway told customers that an outsider may have read environment variables stored on the platform, and that for some of those variables the outsider obtained the decrypted value. Environment variables are where a lot of projects keep API keys, database passwords, and registry credentials. If you don’t have a Railway project, this does not apply to you.

What Railway has published

The first disclosure said the company’s investigation so far indicated unauthorized access to encrypted environment variables and, for some of them, the decrypted contents. Railway said it believed the break-in was part of a series of attacks on hosting platforms aimed at AI inference providers. It paused deployments and told every user to roll environment variables, API keys, and private-registry credentials, and to check provider logs, even though it thought only a subset of users were affected.

A preliminary report the company published afterward is more specific, and it says the forensics are not finished. In that account, the attacker first pulled secrets in encrypted form and could not yet decrypt them. The attacker then reached credentials for Railway’s CI environment and used those to decrypt artifacts. Railway then found a database query of encrypted environment variables, of which a subset were decrypted. Because the values were envelope-encrypted, Railway says that query does not show which individual keys inside an affected project were the ones decrypted.

Railway’s figure for the ceiling is at most 1.85 percent of workspaces, which it says is about 100,000 workspaces. It also says it asked upstream providers to revoke a wider set of keys than that, so more than 100,000 users can see a reset on the provider side even when their workspace was outside the 1.85 percent. The company says the attacker was looking for AI credentials, that workspaces with many variables or many AI keys were the higher risk, and that Railway user accounts were not accessed. It says it is writing to customers with definite impact and to others it considers high risk.

On October 22, Railway said it had reset storage-bucket credentials itself, and had invalidated the GitHub tokens it held. Those GitHub tokens can still work on GitHub’s side until you revoke them. Railway cannot mint a replacement. You reconnect GitHub yourself. Services pick up new bucket credentials on the next deploy.

If you use Railway

1. Rotate secrets that lived in Railway variables, even if you have not received a personal notice. That was the company’s instruction on October 21, and the preliminary report does not narrow it to a list you can check yourself. Include API keys, database credentials, and private-registry logins. Then look at those providers for use you don’t recognize.
2. Revoke the GitHub tokens, don’t only reconnect. Reconnecting gives Railway a new token. The old registry token remains valid at GitHub until you revoke it there.
3. Redeploy anything that reads bucket credentials. Railway says the bucket name and the objects did not change. The access keys did. A running container keeps the old environment until it starts again.
4. A password you only used on a website, and never stored in a Railway variable, is not what this incident describes. The company says it did not access Railway user accounts.

Sources

• Railway, Security disclosure: Wednesday October 21st, October 21, 2026
• Railway, Preliminary report: Oct 21st security incident, October 2026
• Railway, Redeploy buckets and reconnect GitHub after the credential reset, October 22, 2026