Railway Breach: Decrypted Env Vars and $740K in Stolen AI Usage. What to Rotate Now

Railway, the developer hosting platform, published its full incident report on November 10, 2026. It confirms that an attacker who was inside its systems on October 20 and 21 decrypted customer environment variables, went looking specifically for AI provider keys, and that unauthorized usage on those keys was estimated to reach about $740,000. Linked-account tokens for 1,852 users were also exposed.

If you deploy anything on Railway, this is a secret rotation story first and a breach story second. Here is what the report says and what to do about it.

What happened

Railway describes a chain, not a single bug. All times are UTC, from the report:

• Oct 20, 07:28: the attacker exploited a previously unknown flaw in Railway's multi-tenant build infrastructure to partially escape filesystem isolation and read a credential the build servers use for internal systems.
• Railway's internal Temporal cluster accepted that build credential as a trusted client. The attacker read the stored histories of 353 builds, including build variables, and pulled a copy of Railway's internal monorepo.
• Oct 20, 13:58: an alert on anomalous registry API calls paged the on-call engineer. Railway halted builds and replaced the credential that evening.
• Oct 21, 03:26: using the source code, the attacker found an erroneously defined OIDC binding in Railway's CI/CD cloud setup and obtained short-lived cloud credentials. From there they reached an orchestration machine holding a longer-lived key that could decrypt customer variables.
• Oct 21, 04:07 to 07:15: the attacker queried the variables database with regular expressions matching AI provider key names, favoring customers with many variables, and decrypted part of what they pulled. Railway disabled the credentials at 07:14 and says the attacker had no customer data access after 09:25.

Railway says the attacker began creating dummy accounts on October 18 and attacked with AI agents running abliterated models, and calls the response "a contest of agent speed." It believes the stolen keys were passed to resale services for use in model distillation, a pattern commonly called LLMjacking. It cites Wiz's "Black October" research on similar thefts but says that research does not independently attribute this incident.

Who is affected

• Environment variables: at most 1.85% of workspaces, about 100,000, could have had any variable decrypted. Railway stresses this is an upper bound, because its logs identify environments rather than individual variables, and it emailed customers it judged high risk.
• Linked-account tokens: bring-your-own AI agent keys and GitHub OAuth tokens for 1,852 users. Railway reset every one and found no Railway logins with stolen credentials.
• Not affected, per Railway: no evidence of customer databases being accessed or customer repositories being downloaded. Running deployments kept running, but customers who revoked a key could not redeploy until builds returned, which caused downtime for some.

An additional attacker query also matched cloud, database and payment service credentials, so "only AI keys" is not a safe assumption. BleepingComputer's coverage matches the report's figures.

What to do now

1. Rotate everything stored as a Railway variable

Do this even if you did not get an email: the 1.85% figure is a ceiling, not a list. Work in this order: AI provider keys (OpenAI, Anthropic, Google, AWS Bedrock, OpenRouter and similar), then cloud and database credentials, payment keys such as Stripe, and finally webhook secrets and anything else. Revoke the old value at the provider; changing it in Railway alone does nothing.

# List what each service holds, per environment, to build your rotation list
railway link            # pick the project and environment
railway variables       # repeat for every service and environment

2. Check provider usage from October 18 onward

Open the usage dashboard of every AI provider whose key lived on Railway and look for spend, models or regions you do not recognize. Report unauthorized charges through the form linked in Railway's report. Railway says AWS Bedrock and Google are refunding fraud, OpenAI and SpaceXSI review cases through a shared channel with Railway, and Railway itself is covering Anthropic costs for now and all OpenRouter costs.

3. Cap what a stolen key can cost

• Use one key per project and environment, so a leak is easy to scope and revoke.
• Set monthly budgets or spend limits and usage alerts in each provider console. Some providers enforce a hard cap; cloud budgets (AWS, Google Cloud) usually only alert, so wire the alert to someone who can revoke a key at night.
• Review your GitHub account's authorized OAuth apps and audit log, since Railway's GitHub tokens were part of the exposure.

4. Learn from the OIDC mistake

The second route in was a trust relationship that was too broad. If your own pipelines use OIDC to get cloud credentials, check that each binding pins the exact repository, branch or environment it trusts. Our guide to federated identity credentials for GitHub and Entra walks through scoping those subjects, and the Azure Key Vault best practices guide covers keeping secrets out of plain environment variables. For another platform-level incident with the same lessons, see our analysis of the 2026 Vercel breach.

Frequently Asked Questions

Was my Railway workspace affected?

Railway says at most 1.85% of workspaces, about 100,000, could have had environment variables decrypted, and calls that an upper bound. It emailed customers it judged high risk. If you are not sure, treat every variable stored on Railway before October 21, 2026 as exposed and rotate it.

Which secrets should I rotate first?

AI provider keys first, because the attacker's database queries selected them by variable name. Then cloud, database and payment credentials, which an additional query also matched. Then GitHub tokens and every other value stored as a Railway variable.

Will fraudulent AI charges be refunded?

Railway says it is working with providers on refunds and will cover charges that a provider declines to refund, for example OpenRouter, which kept its no-refund policy. Report unauthorized charges through the form linked in Railway's incident report.

How do I stop a stolen AI key from running up a large bill?

Use a separate key per project and environment, set a monthly budget or spend limit with usage alerts in each provider's console, and review usage per key. A limit does not prevent theft, but it caps the damage before you notice.

Sources

• Railway: Incident Report, October 21st Security Attack (Nov 10, 2026)
• BleepingComputer: Railway breach leads to $740,000 in fraudulent AI charges