Security Digest · Oct 21, 2026 · Breach · Cloud
Railway Breach: Rotate Every Secret in Env Variables
Railway says an intruder may have decrypted some customers' environment variables. Rotate every secret stored on Railway at its source and audit its use.
Our verdict
Act now
If you keep any secret in Railway environment variables, rotate it at the provider today and check how it was used; Railway itself tells every customer to do this, and stolen keys were reportedly abused before the disclosure.
Who must act: Every Railway customer that stores API keys, cloud credentials, database passwords, registry tokens or signing keys in Railway environment or shared variables.
Who can relax: Teams that do not use Railway, and Railway projects that hold no secrets; Railway has already rotated bucket credentials and invalidated API tokens itself.
- Affected
- Secrets stored in Railway service and shared environment variables (some decrypted, per Railway)
Private container registry credentials stored in Railway
Railway API and project tokens created before Oct 22, 2026 (invalidated by Railway)
Railway storage bucket credentials (rotated by Railway on Oct 21, 2026) - Fixed in
- No platform fix closes the exposure: rotate each secret at its issuing provider
Railway rotated all bucket credentials (Oct 21) and invalidated all API tokens (Oct 22, 2026) - CVSS
- Not scored
- EPSS
- n/a
- CISA KEV
- Not listed
- Exploitation
- Exploited in the wild
- Severity
- Critical
What to do
- Export the list of every environment and shared variable across all Railway projects and treat each secret as exposed.
- Rotate each secret at its source (AWS/GCP keys, database passwords, Stripe, OpenAI and other AI keys, registry tokens) and deactivate the old value, not just the Railway copy.
- Create new Railway API and project tokens and update CI or scripts that used the old ones.
- Redeploy services so they pick up rotated values; reconnect the GitHub integration if deploys fail.
- Move funds from any wallet whose private key was stored on Railway to a new key.
- Review provider logs and bills for activity you did not generate, as far back as your logs allow.
How to check if you are affected or compromised
- In AWS CloudTrail Event history, look up each old access key ID in every Region and check for RunInstances, CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole and PutBucketPolicy.
- Treat calls with old credentials from IPs outside Railway's egress ranges as suspicious, per Railway's guidance.
- Check OpenAI, other AI-provider and Stripe dashboards for unexpected usage or charges.
- In GitHub, review the organization audit log and personal security logs for new OAuth apps, deploy keys, webhooks, SSH keys and tokens.
- Watch for an email from Railway: it is notifying customers it judges most likely to be affected.
What happened#
On October 21, 2026, the hosting platform Railway disclosed that it had "detected anomalous activity involving systems that store customer environment variables." Its investigation found that an unauthorized party "may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents." Those variables are where Railway users keep API keys, database passwords and registry credentials.
Railway believes the intrusion is "part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers." It says it has asked those upstream providers to revoke keys proactively. Railway has not said how the attacker got in, when access began, or how many customers are affected.
The status page shows the response:
- builds paused platform-wide on October 21
- the security notice posted at 22:10 UTC
- all bucket credentials rotated from 22:37 UTC
- every Railway API token invalidated at 04:39 UTC on October 22
- builds restored tier by tier until 23:22 UTC that day
New signups remain paused. On October 23, Railway began emailing customers it judged to have "a high likelihood of impact," and it said a preliminary incident report was coming.
Who is affected#
Railway says the impact "may be limited to a subset of users," but it recommends that all users rotate their secrets. BleepingComputer puts the platform at about 4.8 million users and more than 16 million hosted services. Exposure is not limited to code that runs on Railway. Any outside system that trusts a key stored there is exposed too: AWS and GCP accounts, managed databases, Stripe, AI providers, container registries and GitHub.
Do you really need to act?#
Yes, if you stored secrets on Railway. "A subset of users" is not a reason to wait. Railway has not said which subset, and it says some values may have been decrypted. Keys also appear to have been used already. Researcher Taylor Monahan reported that cryptocurrency wallets whose private keys were stored on Railway were drained, with the first theft at least two hours before the disclosure (The Hacker News). The AI-inference angle suggests that model-provider keys are a target for running compute on the victim's bill (LLMjacking).
Rotate in this order:
- keys that can spend money or create infrastructure: cloud IAM, AI providers and payments
- database credentials, especially for databases reachable from the internet
- registry and GitHub tokens, which can lead to supply-chain abuse
- everything else
Railway's own credentials (bucket keys and API tokens) have already been reset by Railway. You only need to issue new tokens and redeploy.
What to do now#
- List every service and shared variable in every Railway project and environment, and treat each secret as exposed.
- Rotate each secret at the issuing provider, then deactivate the old value. For AWS, Railway's guide says to create a new access key and then deactivate the exposed one. From the CLI, that is
aws iam update-access-key --user-name USER --access-key-id OLD_KEY_ID --status Inactive. Changing only the Railway copy achieves nothing. - Create new Railway API and project tokens and update any CI or scripts that use them.
- Redeploy so services pick up the new values. If deploys fail, disconnect and reconnect the GitHub integration, as Railway advises.
- Move funds out of any wallet whose key ever lived in a Railway variable.
How to tell if you were hit#
Railway has not published the exposure window, so search as far back as your logs go.
- AWS: look up each old access key ID in CloudTrail Event history, in every Region. Check for
RunInstances,CreateUser,CreateAccessKey,AttachUserPolicy,CreateRoleandPutBucketPolicy. Also download the IAM credential report and compare Cost Explorer with the previous month. Railway advises treating calls from IPs outside its egress ranges as suspicious. - GitHub: Railway's GitHub guide says to export the organization audit log before revoking anything. Then review OAuth and GitHub Apps, deploy keys, webhooks, secrets and collaborators per repository, and personal SSH keys and tokens.
- AI providers and Stripe: check usage dashboards for spend you did not generate.
Also watch for Railway's notification email.
Timeline#
- — Railway detects anomalous activity in its morning, pauses builds, and posts its security disclosure at 22:10 UTC. Bucket credential rotation starts at 22:37 UTC.
- — Railway invalidates all API tokens at 04:39 UTC and publishes provider-specific rotation guides. Builds return for all plans by 23:22 UTC. New signups are paused.
- — Railway begins emailing customers with a high likelihood of impact. The preliminary incident report is still pending.
Sources
Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.
Original and primary sources
- Railway — Security disclosure: Wednesday October 21st blog.railway.com
- Railway Status — Railway platform outage (incident QH8L8B3E) status.railway.com
- Railway — Security disclosure recommendation: check for anomalous AWS access blog.railway.com
- Railway — Security disclosure recommendation: check for anomalous GitHub access blog.railway.com