Railway, a cloud host used by many trading bots and indexers, said on October 21 that an unauthorized party may have read customers' environment variables, the place where a hosted app keeps its API keys and passwords. For some of them the attacker "obtained the decrypted contents". Railway told every customer to roll every secret stored on the platform.
An environment variable is how a program gets its credentials without writing them into the code. A trading bot on Railway typically keeps an exchange API key and secret there, and sometimes a wallet's private key. Railway encrypts the variables at rest, but the platform has to decrypt them to start a deployment. The disclosure says the attacker reached the systems that store them and, in some cases, got the plain text.
What Railway said and when
The post, signed by Jacob Cooper, says Railway detected "anomalous activity involving systems that store customer environment variables" on the morning of October 21. The company believes the intrusion is "part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers". Its first analysis suggests a subset of users is affected. The advice still applies to everyone: roll every variable, every API key and every private registry credential, then review the logs of those services for unusual activity.
The status page gives the timeline in UTC. Railway linked the security notice at 22:10 on October 21 and paused deployments. It rotated its own storage bucket credentials at 22:37. At 04:39 on October 22 it invalidated every Railway API token. Builds came back tier by tier through the day, and the API returned at 17:43 with the old tokens still dead. At 03:00 on October 23 Railway was still emailing customers with a "high likelihood of impact", and a preliminary incident report was promised for around midday Eastern Time.
Detected in the variable storage systems.
Deployments paused, users told to roll secrets.
Every Railway API token killed.
Old API and project tokens stay dead.
Preliminary incident report, midday Eastern.
On October 22 Railway published 13 guides for the services most often wired through its variables: Stripe, OpenAI, Anthropic, OpenRouter, Grok, PostgreSQL, MySQL, Redis, MongoDB, AWS, GCP and GitHub, plus one on redeploying buckets. The Stripe guide, for example, walks through rolling the key, redeploying the service and auditing payouts and webhooks made with the old key. None of the 13 covers a crypto exchange or a wallet. That gap is the reason for this page.
The crypto losses are claimed, not confirmed
CryptoTicker reported on October 22 that security researcher Taylor Monahan counted about $371,000 drained from wallets whose keys sat in Railway variables. The count covers more than 500 transactions, more than 200 addresses and at least 19 blockchains, starting at 19:36 UTC on October 21. The tracker Onchain Lens watched an attacker wallet send at least $369,300 to the exchange HitBTC and called the Railway link unconfirmed. Railway's own statements say nothing about wallets or exchanges.
Two details in those numbers would matter if they hold. The first drains would have started about two and a half hours before Railway's public notice. And 19 chains from one leak fits a private key stored as text, because the same key controls the same address on every Ethereum-compatible network. Neither point is settled until Railway's report says how many accounts were read and when.
What can be rotated and what cannot
An API key can be replaced. A private key cannot. The wallet address is derived from the key, so a leaked key means the whole wallet is exposed until it is emptied into a fresh one. That difference decides the order of work for anyone who ran a bot or a script on Railway.
| Secret stored as a variable | What to do | Where to look for damage |
|---|---|---|
| Exchange API key and secret | Delete it on the exchange and create a new one. Do not re-use the old one. | The exchange's API log and withdrawal history since October 21. |
| Wallet private key or seed phrase | Move the funds to a new wallet and retire the address. | A block explorer, outgoing transfers after 19:00 UTC on October 21. |
| RPC or data provider key | Rotate it in the provider's dashboard. | Usage and billing spikes. |
| Telegram or Discord bot token | Regenerate the token. | Messages or commands the bot did not send. |
| Database connection string | Rotate the password, following Railway's guide for the engine. | Database logs for unknown connections. |
| Railway API or project token | Already invalidated by Railway. Create new ones. | Nothing: the old tokens no longer work. |
The worst case is an exchange key that was allowed to withdraw and had no IP allowlist. Most exchanges let a key trade without withdrawal rights, and a bot rarely needs more. A key created with trade-only permission limits a leak to bad trades, which is the reason our wallet security guide treats permissions as the first setting to check. A key that could withdraw needs the exchange's withdrawal history read line by line.
Railway has not said how many customers were read, whether the decrypted variables were copied in bulk or sampled, or how long the attacker was inside. The preliminary incident report due on October 23 should answer the first two. The wallet drains will stay a claim until Railway, or on-chain evidence that ties the addresses to Railway customers, confirms them. We will update this page when the report lands.
