Railway, the cloud deployment platform, disclosed on October 21, 2026 that an attacker got into the systems that store its customers' environment variables. In Railway's words, an unauthorized third party "may have accessed encrypted environment variables" and, for some of them, "obtained the decrypted contents." Environment variables are where most apps keep their secrets: AI provider keys, database URLs, payment keys, registry credentials. Railway says it believes the intrusion is "part of a series of attacks recently targeting platform companies" with the aim of compromising AI inference providers, and that it notified those upstream providers to revoke keys proactively.
The disclosure came after a day-long platform outage in which the dashboard, API and CLI went down and builds were paused across every region. Railway rotated all storage bucket credentials and invalidated OAuth sessions. Its advice to every customer is blunt: roll all environment variables, API keys and private registry credentials immediately, and review your services' logs. This post lays out the timeline, what is and is not known, and a practical rotation and hunting plan. For context on the campaign, see our OpenRouter breach claim analysis and the OpenCode Console breach.
TL;DR
| Question | Answer |
|---|---|
| What was accessed? | Systems storing customer environment variables; some values decrypted |
| Who is affected? | "May be limited to a subset of users"; affected customers get an email |
| What should everyone do? | Rotate every secret stored in Railway, then review logs |
| Attacker's goal (per Railway) | Compromising AI inference providers |
| Platform status | Builds paused platform-wide; staged return Enterprise → Pro → Hobby → Free |
| Railway actions | Notified AI providers to revoke keys; rotated bucket credentials; invalidated OAuth sessions |
| Root cause | Not disclosed |
| How values were decrypted | Not disclosed |
Timeline (UTC)
From Railway's status page incident QH8L8B3E and its security disclosure:
| Time | Event |
|---|---|
| Oct 21, 07:24 | Railway starts investigating a platform issue |
| 09:28 | Cause identified; dashboard, API and CLI down; new builds paused in all regions; support site affected |
| 11:33 | API partly restored; builds still paused |
| 19:15 | Builds to return in stages: Enterprise, then Pro, Hobby, Free/Trial |
| 20:19 | OAuth sessions invalidated "due to impact from adjacent cache systems"; users must log in again |
| 21:59 | Security notice published: rotate all environment variables, API keys and private registry credentials; review logs; deployments remain paused, including Enterprise |
| 22:10 | All Railway storage bucket credentials being rotated; new values visible, but redeploys blocked until builds resume |
| 22:45 | Bucket credential revocations by a Railway employee will appear in audit logs; expected precaution |
| Oct 22, 00:22 | Builds still paused; guides on next steps "coming soon" |
What is known, and what is not
| Question | Status |
|---|---|
| Encrypted env vars accessed | Confirmed by Railway ("may have accessed") |
| Some values decrypted | Confirmed by Railway |
| Scope | "May be limited to a subset of users"; not quantified |
| Entry point | Not disclosed |
| How decryption happened | Not disclosed; the key question for anyone assessing the platform |
| Link to other platform attacks | Railway's belief; no companies named |
| Abuse of stolen keys | Not reported by Railway; it pre-emptively asked AI providers to revoke |
The undisclosed decryption path matters. If the attacker reached a key-management component or a runtime that holds decrypted values, rotation fixes today's exposure but not the path itself. Until Railway publishes a root cause, assume any secret you set during the exposure window could also be read.
Why AI keys are the target
Railway's framing matches what we saw four days earlier. OpenCode told about 1.4% of its Console users on October 17 that provider keys stored in a legacy system may have been exposed in what it called "a large scale distillation attack," and Anthropic and OpenAI revoked or refunded affected keys. Model API keys are directly monetizable: an attacker can run inference on your bill, resell access, or use frontier models at scale to distill them into their own. A platform that stores thousands of customers' secrets is a concentrated source of those keys.
We covered the cloud version of this, attackers making victims pay for Gemini through hijacked billing accounts, in LLMjacking via billing accounts.
What to rotate, in order
Railway says to rotate everything. Order matters because some keys are abused within hours.
- AI provider keys: OpenAI, Anthropic, Google, OpenRouter, Mistral, Groq, Replicate, ElevenLabs and any other inference key. Create new keys, update Railway, then revoke the old ones at the provider.
- Database and cache credentials: Postgres, MySQL, MongoDB, Redis URLs and passwords. Rotate the credential at the database, not only the variable.
- Payment and messaging: Stripe secret and webhook signing keys, email and SMS providers.
- Auth secrets: OAuth client secrets, JWT signing keys, session secrets, NextAuth or Auth.js secrets. Rotating these logs users out; plan for it.
- Source and registry access: GitHub tokens and deploy keys, npm, Docker Hub, GHCR and other registry credentials Railway used for private images.
- Cloud and storage: AWS, GCP and Azure keys, S3-compatible bucket keys (Railway is rotating its own bucket credentials), Cloudflare tokens.
- Webhooks and integrations: Discord and Slack webhooks, analytics and monitoring keys.
Practical notes while builds are paused:
- You can set new values in Railway now, but they will not reach running services until builds resume. Rotate at the provider in a way that keeps the old key working until the redeploy lands, then revoke the old key immediately after.
- Where a provider supports it, set spend limits per key and restrict keys by IP or project.
- Prefer separate keys per service, so one leak does not expose everything.
How to hunt for misuse
- AI providers: check per-key usage and billing from October 20 onward for spikes, unknown models or unusual hours. Look for new keys or members created in your provider org.
- Databases: review connection logs for unfamiliar IPs and large reads or exports.
- Stripe and payment: check for new webhook endpoints, API keys or payouts.
- GitHub: review the security log for new deploy keys, tokens, OAuth app grants and pushes you did not make.
- Railway: review the audit log and activity panel. Railway says bucket credential revocations by a Railway employee are expected; anything else unexplained is worth a ticket.
If you run AI coding agents, also check whether any agent workspace or MCP server configuration holds copies of the same keys. Rotating the Railway variable does not rotate a copy sitting in a developer's .env or an agent's config. Beam flags agent reads of .env and credential files on developer machines, which helps find where copies live; it does not see your Railway project.
What Railway customers should ask for
- The exposure window, so you can bound log reviews.
- Whether the specific project or service was in the affected subset.
- The decryption path and what has changed to close it.
- Whether variables set after the incident are protected.
Railway says affected customers will be emailed and more guidance is coming. Until then, rotate as if you were affected.
Related reading
- OpenRouter breach claim: what is verified, and the AI key theft campaign
- OpenCode Console breach: provider keys, claimed vs verified
- LLMjacking via hijacked GCP billing accounts
- Anatomy of an AI-driven cloud attack
- Railway, OpenRouter and AI key theft, explained simply on explainx.ai
Primary sources: Railway security disclosure · Railway status incident QH8L8B3E · StartupHub coverage
Accurate as of 00:22 UTC on October 22, 2026. Railway has not published a root cause; check its status page for updates.