Railway security incident of October 21, 2026: roll the Supabase, Stripe and AI keys in your Railway variables, then fix failing deploys

By Ohad Krispin, founder of VibeRaven · LinkedIn

Railway's preliminary report of October 22, 2026 says an attacker had access to internal Railway systems from October 20 at 13:58 UTC to October 22 at 03:32 UTC, pulled encrypted environment variables and decrypted a subset of them, in at most 1.85% of workspaces, about 100,000. Railway cannot tell which variables were decrypted, so it recommends that every customer who signed up before October 21 revoke and replace the sensitive variables stored on Railway. For an app whose Railway service talks to Supabase and Stripe, that means a new Supabase secret key, a new database password in DATABASE_URL, a rotated Stripe secret key and rolled webhook signing secrets, and new AI provider keys, each set again on Railway and wherever else the old value lives. Railway also revoked GitHub connections, API tokens and CLI sessions, so builds fail with "unable to pull repository" or "build could not be started" until you reconnect GitHub, and railway up or a CI deploy fails until you log in again or create a new RAILWAY_TOKEN. Checked against Railway's changelog, incident report and recovery guides on 2026-10-28.

Changing Railway settings this month anyway? See the railway.json cutoff on December 1, 2026.

What happened, from Railway's timeline

Railway's monitoring paged on-call at 13:58 UTC on October 20 for abnormal activity, and Railway halted build pipelines the same afternoon. Early on October 21 the attacker pulled secrets in encrypted form; by 09:18 UTC Railway had found an unauthorized query of encrypted environment variables, a subset of which the attacker decrypted with a combination of compromised credentials, after reaching Railway's CI environment. At 09:25 UTC Railway sent the keys it had registered to vendors and asked them to revoke them, and that evening it invalidated user sessions and published its disclosure. Builds came back for Pro and Enterprise early on October 22, and for every plan by 22:49 UTC that day.

Railway says the attacker was after AI provider API keys, and that two groups were at higher risk: workspaces with a very large number of environment variables, and environments with many AI keys. Running services stayed online the whole time; new builds and deploys were paused.

Which variables to roll

Railway's advice is to roll all environment variables that hold secrets, including API keys and private registry credentials, and to review the logs of those services. In an app built on Supabase, Stripe and an AI API, these are the usual names to look for. A key that is public by design, such as the Supabase publishable or anon key, does not need replacing to stay secret; Supabase's docs say anyone can read it, and RLS is what protects the data.

SUPABASE_SECRET_KEY / SUPABASE_SERVICE_ROLE_KEY   new Supabase secret key
DATABASE_URL / DIRECT_URL                        new database password
STRIPE_SECRET_KEY                                rotated Stripe key
STRIPE_WEBHOOK_SECRET                            rolled endpoint secret
OPENAI_API_KEY / ANTHROPIC_API_KEY / ...         new AI provider keys
RESEND_API_KEY, GitHub tokens, registry logins   new values

Supabase: a new secret key and a new database password

Supabase's API keys guide gives the order for a leaked or compromised key: create a new secret key under Settings > API Keys, replace the old key everywhere the app uses it, confirm that every component uses the new one, then delete the old key, which cannot be undone. For the legacy service_role key, deactivate the legacy keys in the same section instead; that turns off the legacy anon key with it, so switch the client to a publishable key first. The full steps are on rotating a leaked Supabase service role key.

Reset the database password under Database > Settings, then update DATABASE_URL and any DIRECT_URL on Railway. Supabase's troubleshooting answer says a 28P01 error from the shared pooler right after a reset is expected, and a retry with the new password usually succeeds.

Stripe: rotate the secret key and roll each webhook secret

Railway lists Stripe among the vendors it sent keys to, so your Stripe key may already be revoked. Stripe's docs say rotating a key revokes it and generates a replacement that works right away, and that the Dashboard can keep the old and new keys working together for up to 7 days to avoid downtime; for a key that may have leaked, do not keep the old one working. For each webhook endpoint, Roll secret lets you expire the current signing secret now or within 24 hours, and Stripe signs each event with every active secret until then. Put the new values in STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET on Railway.

Builds failing after the incident

Railway's recovery guide gives three causes. Commits pushed while deploys were paused were not queued, so the service keeps its last deployment until you run Deploy Latest Commit from the Command Palette. GitHub connections were revoked, so build errors such as "unable to pull repository" or "build could not be started" mean you need to reconnect GitHub in Account Settings, check that the Railway GitHub App still has the repository, and reconnect the repository in the service settings. API tokens and CLI sessions were revoked too, so the CLI needs a new login and CI needs a new RAILWAY_TOKEN (project token) or RAILWAY_API_TOKEN (account or workspace token) of the same scope.

railway logout
railway login
railway link
railway up

An empty dashboard after logging in again

Railway revoked every login session. Its login guide says to log in with the exact GitHub account or email you signed up with: a different one creates a new, empty account. If you see no projects, log out and retry with the original identity instead of creating new projects.

Checklist

After the October 21 incident

List the environment variable names the app reads, to match against each Railway service:

grep -rhoE "process\.env\.[A-Z0-9_]+" --include=*.ts --include=*.js --exclude-dir=node_modules . | sort -u

02For each secret, create the new value at the provider first, set it on Railway and anywhere else the same value lives, such as Vercel, redeploy, then revoke the old one.
03Supabase: add a new secret key and delete the old one, or deactivate the legacy keys after the switch; reset the database password and update DATABASE_URL.
04Stripe: rotate the secret key and expire the old one now, roll each webhook endpoint secret, then update STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET.
05Remove public network access from databases on Railway, as Railway recommends.
06Review the GitHub audit log and the apps installed on your account or organization, and the activity log of any container registry you use.
07If builds fail, reconnect GitHub, run Deploy Latest Commit, log the CLI in again and replace RAILWAY_TOKEN or RAILWAY_API_TOKEN in your CI secrets.

Sources

Official docs behind this checklist

Browse all launch guides · Read resources · How to make and check your next change

FAQ

FAQ for builders before launch

My services never went down. Do I still need to roll the keys?

Yes. Running deployments stayed online because Railway paused only builds and deploys; that says nothing about whether a variable was decrypted. Railway recommends rotation for every customer who signed up before October 21.

A vendor emailed me that my key was revoked. Did it leak?

Not necessarily. Railway says it sent some vendors every key stored on the platform, and that a vendor notice does not mean the key was affected. Replace the key either way, because the old one no longer works.

Do I need a new Supabase publishable or anon key?

Not to keep it secret, since anyone can read it in the browser. You change it only as a side effect: deactivating the legacy keys turns off the anon key together with service_role, so move the client to a publishable key before you do that.