Railway breach: what happened and what to do

What happened in the Railway breach? On 21 October 2026, Railway said it had detected "anomalous activity involving systems that store customer environment variables", and that an unauthorized third party "may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents"¹. It described the attack as part of a series "targeting platform companies with the aim of compromising AI inference providers", paused all deployments, and recommended that every customer roll every environment variable, including API keys and private registry credentials¹.

If you kept an OpenAI, Anthropic or other AI provider key in a Railway variable, the short answer is: create a replacement, delete the old key at the provider, deploy the replacement as soon as builds are available on your plan, and review the old key's usage. The rest of this page sets out what Railway has confirmed, what it has not, the order of work for AI keys, and what the incident says about the secrets an application holds, including when the holder is us.

What Railway has said

These are Railway's own words, from its disclosure of 21 October¹.

What Railway did, hour by hour

Railway posted its security updates in the status-page incident "Railway Platform Outage"². All times are UTC.

The order matters to anyone rotating. Railway's Anthropic guide says deleting a key in the Claude Console takes effect immediately, and that a Railway service cannot reach Anthropic until the replacement key is deployed³. Its bucket guide adds that containers read variables only at startup⁴. While builds were paused on a plan, rolling an AI key meant taking down whatever used it until that plan's builds returned.

What Railway has not said yet

As of 22 October, Railway has not published:

1. When the unauthorized access began, and how long it lasted.
2. How the attacker reached the systems that store variables, and how decrypted contents were obtained from encrypted ones.
3. How many accounts are in the affected subset, or which variables were read.
4. Which other platform companies the series of attacks reached, and which providers it notified.
5. Whether any exposed secret has been confirmed used.

Railway's own example usage query for Anthropic covers 14 to 21 October³. Until Railway publishes when access began, our reading is that a review window starting no later than 14 October is a sensible minimum, and a wider one costs little.

Why AI provider keys come first

Railway's framing points at them: the attacks it describes aim at "compromising AI inference providers"¹, and the guides it published include usage checks for OpenAI, Anthropic, Grok and OpenRouter beside its database, Stripe and cloud-account checks².

A working AI key is worth more to an attacker than most secrets of its size. It comes with someone else's account, payment method, rate limits and history, so its traffic looks like a paying customer's, and the bill goes to the key's owner. What is LLMjacking and stolen API keys in distillation campaigns explain why such keys are stolen in bulk.

If you stored AI provider keys in Railway

Do this whether or not Railway emails you. The steps follow Railway's own guides for Anthropic and OpenAI³⁵.

1. List every AI key Railway held. Check each service's variables in every environment, and the shared variables in project settings, which every service that references them receives³. Include admin keys, such as Anthropic's sk-ant-admin01- keys and OpenAI's admin keys, and keys for any aggregator or second provider.
2. Check whether your plan can deploy. Deleting a key at the provider takes effect immediately, and your service cannot reach that provider until the replacement is deployed³. Builds came back plan by plan². If yours cannot deploy yet, Railway still recommends rolling immediately¹: decide which features can go dark until it can, and set or lower a spending limit at the provider in the meantime.
3. Create the replacement, then delete the old key. Create it in the same Anthropic workspace or OpenAI project, scoped no wider than before, and copy it, since neither console shows it again. Then delete the exposed key. OpenAI organization-level and legacy user keys are deleted from a different page than project keys⁵.
4. Update the variable and deploy. Edit the variable, once if it is shared, deploy the staged change, and confirm the new deployment's logs show successful calls to the provider³.
5. Review the old key's usage. In the Claude Console, group Usage by API key and compare its token volume and model mix with your normal traffic, then check Cost and Logs; the Usage and Cost Admin API can filter by api_key_ids[]³. In OpenAI, group Usage by API key in the affected project and check Billing and, where enabled, audit logs⁵. A key you use with one model that suddenly shows another is a strong signal³. Signs your AI API key is being abused lists more.
6. Check people, not just keys. Review organization, workspace and project members for anyone you did not invite³⁵.
7. Keep the evidence. Save the usage and cost data for the window, and contact the provider's support with it if you find usage you did not make³⁵.

A key your provider already deactivated still needs a replacement deployed and its usage reviewed³. Provider-specific runbooks: leaked OpenAI API key and leaked Anthropic API key.

The rest of what Railway held

AI keys are rarely the only secrets in a variable list. Railway's guides cover the others²:

• Database credentials. Railway published rotation guides for PostgreSQL, MySQL, MongoDB and Redis; rotate them and redeploy whatever connects.
• Payment and cloud access. Railway published checks for unexpected Stripe usage and for anomalous AWS, GCP and GitHub access.
• What Railway reset for you. It reset the credentials of every storage bucket and the GitHub tokens it held. Services pick up new bucket credentials on their next deploy, GitHub must be reconnected, and GitHub registry tokens must also be revoked on GitHub, where they still work⁴. Railway also invalidated every Railway API token, so CI jobs that call its API need new ones².
• Your audit log. Look for variable reads, registry credential changes and deployments in the window that were made neither by your team nor by Railway Staff⁴.

What this says about secrets in a host's environment

Environment variables are the standard way to hand an application its secrets, and a platform that stores them for every customer concentrates them in one place. Railway encrypted them; its disclosure says that for some of them the attacker obtained the decrypted contents anyway¹. Once a key has left, nothing the host does can limit what is done with it. The incident adds a second cost: rotating means redeploying, so a pause in deployments slows every rotation behind it.

Three questions are worth asking about an application's secrets before the next incident:

How to limit the damage from a stolen AI API key works through each layer.

How INFRO changes what the environment holds

INFRO is a control plane between applications and the AI providers a customer already pays. The application calls INFRO with an INFRO gateway key; the customer's own provider key is connected to INFRO, not set in the application's environment. In an incident like Railway's, that changes three things and leaves the rest as it was.

What changes:

• The provider key is not in the host's environment. A leaked variable holds a gateway key, so there is no provider key to delete and no provider account reachable directly through that variable.
• The exposed key can be contained without a deploy. From the INFRO console you can turn the key off (its requests return 403 with code key_disabled), limit it to your servers' networks where your host gives them fixed outbound addresses (up to 32 addresses or CIDR ranges on every plan; other callers get 403 ip_not_allowed), lower its daily, weekly, monthly or lifetime spend limit (402 with code key_budget), or narrow the models it may call. Each is checked before the provider is called. Turning the key off stops your application too; narrowing its networks or its limit can keep the application running until you can deploy a replacement. See Authentication and spend controls.
• You can see what the key did. Each request record names the gateway key that made it, and spend alerts compare each scope's day with its usual day. Nothing is scored before a quarter of the UTC day has passed, so a spend limit, not an alert, is the first line.

What does not change:

• The gateway key is still a secret, and it still has to be rotated once you can deploy. Rotation takes an overlap window, or none when the old key must stop at once.
• Database credentials, payment keys and registry tokens are outside INFRO entirely.
• INFRO is itself a platform that stores provider keys, the kind of company Railway says these attacks target. Each provider credential is encrypted with AES-256-GCM under a key held as a Worker secret outside the database, with the organization and connection bound in, and no endpoint, console screen or export returns it; gateway keys are stored only as a SHA-256 hash. If a provider key were nonetheless taken from INFRO, it could be used directly against the provider, outside every INFRO limit. That is why we recommend connecting a key scoped to its own project or workspace, with a spending limit set at the provider. It is the control that holds even if we fail.

Summary

Railway says an unauthorized party reached the systems that store customer environment variables and decrypted some of them, in a series of attacks aimed at AI inference providers; it has not published when access began or how many accounts are affected. Roll every variable it held, AI provider keys first: replace, delete at the provider, deploy when your plan's builds allow, and review each old key's usage from 14 October at the latest. Then look at what your application's environment holds, and make sure every key that can spend money has a limit you can move without a deploy.