Railway Breach: Environment Variables Accessed, Some Decrypted, in a Campaign Targeting AI Inference Keys

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

Update (October 23, 2026): Railway's preliminary report puts the scale at about 100,000 workspaces

Railway published a preliminary report on October 22 that answers several open questions above. Its forensic investigation is still ongoing, and it says it will publish a follow-up.

• Scale: Railway says "at most 1.85% of all workspaces had some environment variables potentially compromised," about 100,000 workspaces. Because it could not tell which variables were decrypted, it sent providers up to all the keys it stored, so more users saw upstream revocation emails than that figure. A revocation email does not mean your credential was stolen.
• Window: the attack ran from October 20 13:58 UTC to October 22 03:32 UTC, the point at which Railway confirmed the attacker no longer had access.
• How it progressed: Railway describes a privilege escalation in its build infrastructure, then access to encrypted secrets, then credentials to its CI environment, where the attacker decrypted artifacts holding further API access. A subset of environment variables was then decrypted. Railway has not shared the specific exploits.
• Attacker's aim: logs of the attacker's payloads showed the API key names being searched for. Railway says the goal was AI and platform keys for distillation, and that the two highest-risk groups were workspaces with very many variables and workspaces holding many AI vendor keys.
• Accounts and code: Railway says user accounts were not logged into, but has not ruled out access to user source code until the final report.
• Guidance: rotate everything stored in Railway if you signed up before October 21, remove public network access to databases, and check GitHub and registry audit logs. Railway also rolled all GitHub App installations, so you may need to reconnect GitHub and recreate CLI and CI credentials. Commits pushed while deployments were paused were not deployed.

The earlier advice stands: the status of "not confirmed affected" is not "safe."

Timeline (UTC)

From Railway's status page incident QH8L8B3E and its security disclosure:

What is known, and what is not

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.

1. 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.
2. Database and cache credentials: Postgres, MySQL, MongoDB, Redis URLs and passwords. Rotate the credential at the database, not only the variable.
3. Payment and messaging: Stripe secret and webhook signing keys, email and SMS providers.
4. Auth secrets: OAuth client secrets, JWT signing keys, session secrets, NextAuth or Auth.js secrets. Rotating these logs users out; plan for it.
5. Source and registry access: GitHub tokens and deploy keys, npm, Docker Hub, GHCR and other registry credentials Railway used for private images.
6. Cloud and storage: AWS, GCP and Azure keys, S3-compatible bucket keys (Railway is rotating its own bucket credentials), Cloudflare tokens.
7. 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
• Monitor a Railway-hosted app for attacks with beam monitor
• Your first 24 hours after a vendor breach: a rotation and monitoring runbook
• API keys in logs and env vars: how they leak and how to catch it
• TypeSafe AI's "customer output leak" was a joke; October's attacks are not

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.