# Railway breach: what happened and what to do

URL: https://infro.io/blog/railway-breach-what-happened
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-22
Last modified: 2026-10-22
Last reviewed: 2026-10-22 (next review due 2026-10-29)
Topic: Security and governance
Format: Analysis

> Railway said on 21 October 2026 that an unauthorized third party may have accessed encrypted customer environment variables and, for some of them, obtained the decrypted contents, in a series of attacks on platform companies aimed at compromising AI inference providers. It recommends that every customer roll every variable, including API keys and private registry credentials, and review logs. If an OpenAI, Anthropic or other AI provider key was stored in Railway, create a replacement, delete the old key at the provider, deploy the replacement once builds are available on your plan, and review the old key's usage, whether or not Railway emails you.

Key takeaways:
- Railway says an unauthorized party may have accessed encrypted environment variables and decrypted some of them; it asks every customer to roll every variable, not only those it emails.
- Railway ties the attack to a series targeting platform companies to compromise AI inference providers, so AI provider keys are the secrets to rotate first.
- Deleting a provider key takes effect at once, but a Railway service picks up the replacement only on its next deploy, and builds came back plan by plan.
- Railway has not published when access began, how many accounts are affected or how decrypted contents were obtained; review usage generously until it does.
- Before the next incident, find the secrets that can spend money on their own and give each a limit you can move without a deploy.

**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"[1]. 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[1].

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.

> **Note: This is an ongoing incident**
> Written on 22 October 2026 from Railway's own disclosure, status page and guides. Railway says it will update its announcement as it narrows the scope of impact, so some details below may change. This page is reviewed weekly while the incident is open, and each change will be dated in its revision notes.

## What Railway has said

These are Railway's own words, from its disclosure of 21 October[1].

| Statement | What it means for you |
| --- | --- |
| "anomalous activity involving systems that store customer environment variables", detected on the morning of 21 October | The store of every customer's variables was the target, not individual applications |
| An unauthorized third party "may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents" | Encryption did not keep every value secret; treat values as readable |
| Environment variables "may contain secrets such as API keys or database and registry credentials" | Anything you set as a variable is in scope |
| Part of "a series of attacks recently targeting platform companies with the aim of compromising AI inference providers" | AI provider keys are what the attackers were after |
| Railway notified those upstream providers "to revoke all keys proactively" | An AI key you kept on Railway may already have stopped working |
| The impact "may be limited to a subset of users", but every user should act as a precaution | Do not wait for an email |
| Roll all environment variables, including any API keys, and private registry credentials, and review logs for unusual activity | Railway's recommendation to every customer |
| All deployments paused while Railway investigates | A rolled variable reaches a service only when it can deploy |
| Affected customers will be emailed as Railway confirms them | The list of affected accounts may still change |

## What Railway did, hour by hour

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

| Time | Update |
| --- | --- |
| 21 Oct, 07:24 | Incident opened: investigating |
| 21 Oct, 09:28 | Dashboard, API and CLI unavailable; new builds paused in all regions |
| 21 Oct, 20:19 | OAuth sessions invalidated; affected users signed out |
| 21 Oct, 21:59 | Security notice published |
| 21 Oct, 22:10 | Credentials of every storage bucket being rotated |
| 22 Oct, 01:22 | Step-by-step recommendation guides published |
| 22 Oct, 03:32 | Builds available for Enterprise workspaces |
| 22 Oct, 04:17 | Every Railway API token invalidated |
| 22 Oct, 06:29 | Builds available for Pro workspaces |
| 22 Oct, 16:14 | Pro and Enterprise deployments at normal speed; Hobby next, then Free and Trial |

Table: Railway's status-page updates, 21 and 22 October 2026

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[3]. Its bucket guide adds that containers read variables only at startup[4]. 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[3]. 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"[1], and the guides it published include usage checks for OpenAI, Anthropic, Grok and OpenRouter beside its database, Stripe and cloud-account checks[2].

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](https://infro.io/blog/what-is-llmjacking) and [stolen API keys in distillation campaigns](https://infro.io/blog/stolen-api-keys-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[3][5].

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[3]. 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[3]. Builds came back plan by plan[2]. If yours cannot deploy yet, Railway still recommends rolling immediately[1]: 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[5].
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[3].
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[]`[3]. In OpenAI, group Usage by API key in the affected project and check Billing and, where enabled, audit logs[5]. A key you use with one model that suddenly shows another is a strong signal[3]. [Signs your AI API key is being abused](https://infro.io/blog/signs-ai-api-key-abused) lists more.
6. **Check people, not just keys.** Review organization, workspace and project members for anyone you did not invite[3][5].
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[3][5].

A key your provider already deactivated still needs a replacement deployed and its usage reviewed[3]. Provider-specific runbooks: [leaked OpenAI API key](https://infro.io/blog/leaked-openai-api-key) and [leaked Anthropic API key](https://infro.io/blog/leaked-anthropic-api-key).

> **Example: One service's rotation**
> A Pro workspace runs one API service with an Anthropic key and an OpenAI project key in shared variables. Once builds are back for Pro, the team creates both replacements, deletes the old keys, updates the shared variables once and deploys. It groups Anthropic and OpenAI usage by key from 14 October, finds only its own model mix, exports both reports and files them with the incident ticket. Total time: about forty minutes, most of it in the deploy queue.

## The rest of what Railway held

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

- **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[4]. Railway also invalidated every Railway API token, so CI jobs that call its API need new ones[2].
- **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[4].

## 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[1]. 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:

| Question | Why it matters |
| --- | --- |
| Which secrets in this environment can spend money on their own? | Those are the ones an attacker uses first, and the ones to rotate first. |
| Can each one be limited, narrowed or switched off without a deploy? | When deploys are paused, controls that live outside the application are the only ones you can still move. |
| Does each provider key carry a spending limit at the provider? | That limit still applies after the key has left every system you control. |

[How to limit the damage from a stolen AI API key](https://infro.io/blog/cap-stolen-ai-key-damage) 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](https://infro.io/docs/authentication) and [spend controls](https://infro.io/docs/org/spend-controls).
- **You can see what the key did.** Each request record names the gateway key that made it, and [spend alerts](https://infro.io/docs/observability/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.

## Questions

### Was my Railway account affected?

Railway said its initial analysis suggests the impact may be limited to a subset of users, that it will email the customers it confirms were affected, and that every user should take the recommended actions as a precaution while it completes its review. Not having an email yet does not mean none of your variables were exposed.

### Did Railway reset any credentials for me?

Some. Its status page says it rotated the credentials of every storage bucket, invalidated every Railway API token and invalidated OAuth sessions, signing some users out; its guide adds that it reset the GitHub tokens it held. Services that read bucket credentials need a redeploy, Railway API tokens must be recreated and GitHub must be reconnected. Your own variables, including AI provider keys, are yours to roll.

### Can I deploy on Railway again?

Builds came back in stages: Enterprise workspaces at 03:32 UTC on 22 October and Pro workspaces at 06:29 UTC. At Railway's 16:14 UTC update the same day, Hobby was next, followed by Free and Trial. The status page has the current state for each plan.

### My AI provider already deactivated the key. Is there anything left to do?

Yes. Railway says it asked the upstream AI providers to revoke keys proactively, and its Anthropic guide notes that a key already deactivated still needs a replacement deployed and its usage reviewed. A revoked key ends future misuse; it does not tell you what happened before.

## Sources

1. Security Disclosure: Wednesday October 21st — Railway. https://blog.railway.com/p/security-disclosure-wednesday-october-21st (accessed 2026-10-22)
2. Railway Platform Outage (status-page incident carrying the security updates) — Railway. https://status.railway.com/incident/QH8L8B3E (accessed 2026-10-22)
3. Security Disclosure Recommendation: Check for Unexpected Anthropic Usage — Railway. https://blog.railway.com/p/security-disclosure-recommendation-check-for-unexpected-anthropic-usage (accessed 2026-10-22)
4. Security Disclosure Recommendation: Redeploy Buckets and Reconnect GitHub After the Credential Reset — Railway. https://blog.railway.com/p/security-disclosure-recommendation-redeploy-buckets-and-reconnect-github-after-the-credential-reset (accessed 2026-10-22)
5. Security Disclosure Recommendation: Check for Unexpected OpenAI Usage — Railway. https://blog.railway.com/p/security-disclosure-recommendation-check-for-unexpected-openai-usage (accessed 2026-10-22)