Railway Breach: Rotate Every Secret, Starting With AI Keys

Introduction

On October 21, 2026, Railway said it had detected anomalous activity in the 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” (Railway). Railway believes the impact may be limited to a subset of users, but it asked every customer to roll all environment variables, including API keys and private registry credentials, and to review the logs of those services for unusual activity.

Railway also said it believes the incident is part of a series of attacks on platform companies aimed at compromising AI inference providers. That matters for anyone who deployed an AI-built app there: the environment variables usually hold the OpenAI or Anthropic key, the Stripe key and the database URL. This guide covers what to rotate first, how to do it without a long outage, how to tell whether a key was already used, and what to change so the next platform incident costs less.

What has Railway confirmed about the breach?

Railway confirmed that someone may have accessed encrypted customer environment variables and decrypted some of them. It paused deployments, asked every customer to rotate all variables and review service logs, and said it will email affected customers once it narrows the scope.

The disclosure, written by Jacob Cooper, says Railway notified upstream providers so they could revoke exposed keys proactively, and that it will post updates on its blog and at status.railway.com. While deployments are paused, you can’t roll out new versions, which shapes how you rotate (more on that below). Railway hasn’t said how the attacker got in, and the disclosure doesn’t mention sealed variables, so treat those as in scope too, as GitGuardian recommends.

The same week also brought PHP2Shell, two critical PHP flaws that led governments and companies to take websites offline. TechCrunch reports that the Railway attack appears to be separate.

Why are AI provider keys the first thing attackers go after?

An AI provider key is a payment method. Whoever holds it can run models on your account until the key is revoked or a spending limit stops them, and Railway says this campaign targets AI inference providers specifically. Rotate AI keys before anything else.

A similar incident shows what that costs. On October 17, the AI coding tool OpenCode disclosed that attackers reached its console through a legacy system and that third-party provider keys saved there, such as OpenAI and Anthropic keys, may have been exposed. TechCrunch reported users finding unauthorized charges on their AI accounts overnight.

In what order should you rotate your secrets?

Rotate in the order of damage: keys that spend money first, then keys that reach customer data, then everything else. For each one, change it at the provider first and update Railway second, so the old value stops working as soon as possible.

1. AI provider keys: OpenAI, Anthropic, Google, and any other model or inference API. Set a spending limit on the new key while you’re there.
2. Payment credentials: Stripe secret and restricted keys, and webhook signing secrets.
3. Database access: connection strings, database passwords, and service-role keys such as Supabase’s.
4. Cloud and registry credentials: AWS and GCP keys, and private container registry credentials, which Railway names specifically.
5. Authentication secrets: OAuth client secrets, session secrets and JWT signing keys.
6. Everything else: email, SMS, analytics, search and storage providers.

GitGuardian’s guidance follows the same principle: rotate in the upstream service (AWS, GCP, GitHub, the AI provider) before updating the value in Railway, then redeploy and check the services that depend on it. Delete any local copy of your variables once you’re done.

How do you rotate secrets without taking your app down?

Where a provider allows it, create the new credential alongside the old one, switch the app over, confirm it works, then revoke the old one. The catch this week is that Railway paused deployments, so the app can’t pick up new values until builds return.

That leaves a trade-off for each secret. For an AI key, revoke it now even if the feature that uses it goes down; a few hours without AI is cheaper than an open-ended bill. For a database password or Stripe key, revoking before you can redeploy takes the app offline, so add the new credential, check the provider’s usage and logs, and plan the switch for the moment builds are back. Two kinds of secret need extra care:

• Session and JWT signing secrets: rotating them signs every user out. That’s usually acceptable after a breach, but tell your users first.
• Webhook signing secrets: some providers, Stripe among them, let you roll a signing secret and keep the old one valid for a short overlap, so in-flight events still verify.

Keep a simple list of each secret, where it’s used, the time you rotated it, and the time you revoked the old value. You’ll want it when you check usage, and again the next time this happens.

How do you tell whether a key was already used?

Check each provider’s own usage and audit logs for the past few weeks: unfamiliar models, calls at hours your app is quiet, new IP addresses, and sudden spikes. Railway asks customers to review the logs of every service whose credentials were stored there.

• AI providers: usage by key, model and day in the provider dashboard. If you can’t separate your own traffic, that’s a reason to use one key per app.
• Cloud accounts: AWS CloudTrail and GCP audit logs for API calls from unknown addresses. Railway has published follow-up posts on checking for anomalous AWS and GCP access.
• Databases: connections from addresses outside your app, and unusual reads or exports.
• Stripe and other payment providers: new API keys, changed webhook endpoints, and refunds or payouts you didn’t make.

If you find misuse, revoke the key immediately, keep the logs, and contact the provider about the charges.

What should you change so the next platform breach costs less?

Assume another platform you depend on will leak secrets one day. Smaller, scoped, capped and listed secrets turn that day from a crisis into an afternoon of rotation.

• One key per app and environment, so you can tell usage apart and revoke one without breaking the rest.
• Spending limits on every AI key, and restricted keys wherever a provider offers them, such as Stripe restricted keys with only the permissions the app needs.
• Short-lived credentials instead of long-lived keys where your stack supports them.
• A written inventory of every secret, where it lives and how to rotate it.
• Secrets kept out of code, chats and screenshots, and scanned for regularly. Our free Secret Scanner skill checks a repository for exposed credentials.

The Zenveus Fix Library covers the most common ways secrets leak from AI-built apps: an AI API key exposed in frontend code, a database URL exposed in the browser, a .env or backup file that anyone can download, and a default admin password or session secret.

Why is a hosting breach a production readiness question?

Rotating keys is the urgent part. The lasting question is how much one leaked variable can do: whether a stolen key can drain an account, read every customer’s data, or deploy code. That depends on how the app was built, not on the host.

Secret and key management is one of the nine checks in the Zenveus Production Readiness Standard. If you’d like an engineer to answer it for your app, the 48-Hour Verdict puts a named senior engineer on your codebase for $299 and returns a signed written decision against the Standard. When the concern is specifically who can reach your data and keys, the Security & Data Isolation Audit is a fixed-scope review of authentication, authorization, tenant isolation, secrets, APIs, webhooks, dependencies and storage permissions.

For every incident we are tracking that affects AI-built apps, with what to do for each, see Security alerts for AI-built apps.

NEXT STEP

Find out how far one leaked key could reach

A named senior engineer reviews your codebase against the Production Readiness Standard and signs a written verdict in 48 hours: which secrets are exposed, what they unlock, and what to fix first.

Get the 48-Hour Verdict ($299)

Sources

• Railway: Security Disclosure, Wednesday October 21st
• TechCrunch: Railway urges all users to revoke secret keys after cyberattack (October 22, 2026)
• GitGuardian: New Railway incident, treat every env variable as exposed
• TechCrunch: hackers hit AI coding tool OpenCode, running up charges on users’ AI accounts (October 19, 2026)