On October 21, 2026, the cloud hosting platform Railway disclosed that an unauthorized party may have accessed the systems that store customers' environment variables, and for some of them obtained the decrypted values. Environment variables are where apps keep their secrets: database passwords, API keys for services like OpenAI, Anthropic, Stripe and AWS, and private registry credentials. Railway believes only a subset of users were affected, but it is asking every user to rotate those secrets now (Railway).
If your app, or an app someone built for you, runs on Railway, don't wait for an email. Assume every secret stored there is exposed, and replace it. The step-by-step plan is below.
What happened
Railway says it detected anomalous activity in the systems that store customer environment variables. In its words, an unauthorized third party "may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents" (Railway disclosure).
Railway's response, from its status page and disclosure:
- Paused all builds and deployments on October 21 while it investigated, so customers couldn't ship new code.
- Logged everyone out by invalidating OAuth sessions, and later invalidated all Railway API tokens. Tokens created before the incident no longer work.
- Rotated all storage bucket credentials on customers' behalf.
- Asked AI inference providers to revoke keys proactively, because it believes the attack is part of a campaign against platform companies aimed at AI providers.
- Published security guides for checking AWS, GCP and GitHub for misuse.
- Paused new signups to focus on existing customers.
Builds came back in stages through October 22, starting with Enterprise and ending with Free and Trial plans. As of the morning of October 23, Railway reports builds and deployments running normally, and says a preliminary incident report is on the way (status page).
What's confirmed and what isn't
Railway hasn't explained how the attacker got in, and a lot of what's circulating online is unverified. Here's how the claims stand as of October 23:
| Claim | Status |
|---|---|
| Encrypted environment variables may have been accessed, some decrypted | Confirmed by Railway |
| Impact may be limited to a subset of users | Railway's initial analysis |
| Number of affected accounts | Not disclosed |
| How the attacker got in (root cause) | Not disclosed; a post-mortem is promised (TechCrunch) |
| Part of a wider campaign targeting AI inference providers | Railway's stated belief, not independently verified |
| Whether "sealed" variables were in scope | Not stated, so security firms advise rotating them too (GitGuardian) |
| Stolen AI and payment keys being abused | Individual reports from developers, not confirmed by Railway (Open Class Actions) |
| About $371,000 drained from crypto wallets with keys on Railway | One researcher's claim, not confirmed by Railway (report) |
Railway says it is emailing customers with a high likelihood of impact. Not getting an email yet doesn't mean you're in the clear.
Why this matters even if you never chose Railway
Railway is popular for hosting backends, APIs and databases because it's fast to set up, which also makes it a common choice for apps built quickly, including with AI coding tools. Many business owners have an app running on a platform like Railway without knowing it, because a freelancer or a tool picked it.
If someone built you an app in the last couple of years, ask them where it's hosted. If the answer is Railway, the steps below apply to you.
The pattern: attackers want your API keys
This isn't an isolated event:
- Earlier the same week, the open-source AI coding tool OpenCode disclosed that attackers took more than 1% of its customers' API keys and other secrets (TechCrunch).
- In April 2026, Vercel had an incident involving customer environment variables (GitGuardian).
- The same week, the PHP2Shell vulnerabilities showed that attackers can also pull secrets like API keys straight out of an unpatched server's memory.
AI API keys are valuable on their own. A stolen OpenAI or Anthropic key can run up thousands of dollars of usage on your bill, or be resold. Payment and cloud keys can do far worse. Your hosting platform is one of the most sensitive places your business data lives.
What to do now: a step-by-step plan
The order matters. Always create the new secret at the source first, update Railway, redeploy, and only then revoke the old one. Otherwise your app goes down mid-rotation.
1. Make a list of every secret
Open each Railway project and service, and list every variable: shared project variables, service variables, and each environment (production, staging, preview). With the Railway CLI you can export a service's variables (railway variable list --kv) to work from. Delete that file when you're done.
GitGuardian suggests scanning the export to find which values are live secrets, which gives you a prioritized list (GitGuardian).
2. Rotate in order of damage
| Priority | Secret | Why |
|---|---|---|
| 1 | Payment keys (Stripe, PayPal, Square) | Direct financial risk |
| 2 | Cloud credentials (AWS, GCP, Azure) | Can create servers, read storage, run up huge bills |
| 3 | AI provider keys (OpenAI, Anthropic, Google, others) | The apparent target of this campaign; billed per use |
| 4 | Database passwords and connection strings | Direct access to customer data |
| 5 | Source code and deploy tokens (GitHub, GitLab, private registries) | Can lead to tampered code |
| 6 | Email, SMS and CRM keys (SendGrid, Twilio, HubSpot) | Phishing from your real domain, data access |
| 7 | App secrets (JWT signing keys, session secrets, webhook secrets, OAuth client secrets) | Forged logins and requests; rotating signs users out |
| 8 | Everything else, including "sealed" variables | Railway hasn't said they were safe |
For each one: create the new key at the provider, update the value in Railway, redeploy, confirm the app works and the logs show no auth errors, then revoke the old key. Update any copies in CI, local .env files or other hosts at the same time.
3. Check for misuse
Rotating stops future abuse. You also need to know whether a key was already used:
- AI providers: check usage dashboards and invoices for spikes since mid-October. Set hard spending limits if you haven't.
- AWS: search CloudTrail by the old access key ID in every region, look for new users, keys, instances or changed bucket policies, and compare Cost Explorer against last month (Railway's AWS guide). Railway has GCP and GitHub guides too.
- Stripe and payment providers: review API request logs, new webhooks, payouts and refunds.
- Databases: look for connections from unfamiliar IP addresses, new users and large exports.
- GitHub: check the security log for new deploy keys, tokens, webhooks or unexpected commits.
If you find misuse, keep evidence (screenshots, logs) before cleaning up, and check whether customer personal data was involved. That can trigger notification duties.
4. Reconnect and clean up
- Create new Railway API tokens for CI and scripts. The old ones no longer work.
- If deployments fail, Railway suggests disconnecting and reconnecting the GitHub integration.
- Redeploying code from before the incident may fail, so deploy a fresh build.
Lessons for any business running an app
Use scoped, limited keys. Give each app its own key with only the permissions it needs, separate keys for production and staging, and spending caps on AI and cloud accounts. A leaked key with a $100 monthly limit is an annoyance. An unlimited admin key is a disaster.
Keep an inventory of secrets. You can't rotate what you don't know about. A simple list of every key, where it lives and who owns it turns a panicked weekend into an afternoon.
Know what your provider owes you. Railway's terms of service cap its liability at the greater of $100 or what you paid in the previous 12 months, and exclude lost profits and lost data (Railway terms, as summarized by Dennis Weidner). Most hosting platforms have similar terms. The cleanup cost is yours, so plan for it.
Fast to build isn't the same as ready for production. Platforms like Railway, and the AI tools that deploy to them, make it easy to get an app live. They don't decide who rotates keys, monitors usage or reads the security notices. Our checklist for taking a Lovable or Bolt app to production covers the basics, and when you hire a development company, ask who owns this work after launch.
Need help rotating keys or checking your app?
If you have an app on Railway and aren't sure what's stored there or how to rotate it safely, we can help. Our app rescue service reviews AI-built and fast-built apps and closes security gaps like exposed keys and missing access rules. We can map where your secrets live, rotate them in the right order, and check connected accounts for misuse. For ongoing coverage, our care plans include security monitoring and updates.
Tell us about your app and we'll get back to you quickly.
Sources
- Railway: Security Disclosure: Wednesday October 21st, incident status page, guides for AWS, GCP and GitHub, terms of service
- TechCrunch: Developer platform Railway urges 'all users' to revoke secret keys after cyberattack
- GitGuardian: New Railway incident: treat every env variable as exposed, Vercel April 2026 incident
- Cybersecurity News: Railway security incident
- Open Class Actions: Railway hack: API keys, passwords and AI accounts exposed
- Dennis Weidner: Railway security incident: why liability stops at $100
This post reflects what was public as of October 23, 2026. Railway has promised a preliminary report and a post-mortem; we'll update this post when they're published.