--- title: "Railway Breach: Rotate Every Secret in Env Variables" url: https://erroneo.us/security/briefs/railway-environment-variable-secrets-breach/ description: "Railway says an intruder may have decrypted some customers' environment variables. Rotate every secret stored on Railway at its source and audit its use." type: security-brief section: "Security Digest" date_published: 2026-10-21 date_modified: 2026-10-23 publisher: erroneo.us author: erroneo.us Security Desk verdict: "Act now" cves: [] severity: "critical" exploited: "in-the-wild" kev: false license: All rights reserved. Quote with attribution and a link. --- # Railway Breach: Rotate Every Secret in Env Variables **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:** 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) - **CVEs:** none - **CISA KEV:** no · **Exploitation:** Exploited in the wild ## What to do 1. Export the list of every environment and shared variable across all Railway projects and treat each secret as exposed. 2. 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. 3. Create new Railway API and project tokens and update CI or scripts that used the old ones. 4. Redeploy services so they pick up rotated values; reconnect the GitHub integration if deploys fail. 5. Move funds from any wallet whose private key was stored on Railway to a new key. 6. 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 - 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](https://blog.railway.com/p/security-disclosure-wednesday-october-21st) 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](https://status.railway.com/incident/QH8L8B3E) 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](https://www.bleepingcomputer.com/news/security/railway-warns-devs-to-rotate-secrets-after-potential-breach/) 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](https://thehackernews.com/2026/10/railway-says-intruder-may-have-accessed.html)). 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: 1. keys that can spend money or create infrastructure: cloud IAM, AI providers and payments 2. database credentials, especially for databases reachable from the internet 3. registry and GitHub tokens, which can lead to supply-chain abuse 4. 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 1. List every service and shared variable in every Railway project and environment, and treat each secret as exposed. 2. Rotate each secret **at the issuing provider**, then deactivate the old value. For AWS, Railway's [guide](https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-aws-access) 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. 3. Create new Railway API and project tokens and update any CI or scripts that use them. 4. Redeploy so services pick up the new values. If deploys fail, disconnect and reconnect the GitHub integration, as Railway advises. 5. 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`, `CreateRole` and `PutBucketPolicy`. 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](https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-github-access) 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 - Oct 21, 2026 — 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. - Oct 22, 2026 — 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. - Oct 23, 2026 — Railway begins emailing customers with a high likelihood of impact. The preliminary incident report is still pending. ## Sources 1. [Railway — Security disclosure: Wednesday October 21st](https://blog.railway.com/p/security-disclosure-wednesday-october-21st) 2. [Railway Status — Railway platform outage (incident QH8L8B3E)](https://status.railway.com/incident/QH8L8B3E) 3. [Railway — Security disclosure recommendation: check for anomalous AWS access](https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-aws-access) 4. [Railway — Security disclosure recommendation: check for anomalous GitHub access](https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-github-access) 5. [BleepingComputer — Railway warns devs to rotate secrets after potential breach](https://www.bleepingcomputer.com/news/security/railway-warns-devs-to-rotate-secrets-after-potential-breach/) 6. [The Hacker News — Railway says intruder may have accessed customer secrets, urges credential rotation](https://thehackernews.com/2026/10/railway-says-intruder-may-have-accessed.html) --- Source page: https://erroneo.us/security/briefs/railway-environment-variable-secrets-breach/ · Security Digest: https://erroneo.us/security/ · More: https://erroneo.us/llms.txt