Security briefs

Were my Railway environment variables stolen, and what should I rotate?

By Brandon Da Costa, founder of Digiton Dynamics

Published 26 October 2026Updated 26 October 2026Editorial policy

Railway says an attacker read encrypted environment variables and decrypted some of them. It wants every customer who signed up before 21 October 2026 to rotate whatever Railway stores. The attacker was hunting AI provider keys, so start there.

Who should act: Anyone who kept an API key, database password or registry credential as a Railway variable before 21 October 2026, on any plan.

What happened

Railway's disclosure of 21 October says it detected anomalous activity in systems that store customer environment variables, and that an unauthorized third party may have decrypted some of them. Its preliminary report, dated 22 October, says the attacker was after AI provider API keys, which Railway believes were wanted for distillation attacks.

At most 1.85 percent of workspaces, about 100,000, had variables potentially compromised. Railway cannot tell which, because the keys were envelope encrypted, so it asked vendors to revoke up to every key it stored. That is why GitHub, GitLab, Anthropic, OpenAI, OpenRouter and Stripe sent revocation emails. Railway also invalidated all API tokens (status page, 22 October, 04:17 UTC) and reset every storage bucket credential (21 October, 22:37 UTC).

The sources disagree in places. The disclosure says Railway detected the activity on the morning of 21 October. The report dates the first alert 13:58 UTC on 20 October. Aviatrix (22 October) calls it LLMjacking, stolen AI keys run at the victim's cost, and reports crypto wallets drained on-chain, with no total. Railway's report mentions no wallet theft, and Railway has not confirmed any loss.

Who is affected

• Any workspace that stored keys, passwords or registry credentials as variables before 21 October. Railway recommends that all of them rotate (Railway, 22 October).
• Workspaces with very many variables, or many AI keys. Railway names these as the high-risk groups and finished emailing them on 23 October. Others are not confirmed safe (status page, 23 October).
• Pipelines that deploy from CI or the CLI. Tokens made before the incident stay invalid.

A provider's revocation email does not prove your key was hit, because Railway sent some vendors every key it held. Running services stayed online, while builds, deploys, the dashboard and the API were interrupted. Railway has not ruled out source code access until its final report.

What we checked

Run on 26 October 2026 on the Mac that builds this site. Each command and its output are copied as they ran.

$ railway --version
railway 4.31.0

$ railway variable list --help | grep -E -- '--(kv|json)'
  -k, --kv                         Show variables in KV format
      --json                       Output in JSON format

$ curl -s https://status.railway.com/incident/QH8L8B3E | grep -o 'This incident has been resolved' | head -1
This incident has been resolved

The two Railway CLI flags used in step 1 exist in the version installed here, and Railway's status page shows the incident as resolved.

What to do now

1. List what Railway holds for you, names only, for each service and environment.

   railway variable list --kv | cut -d= -f1

2. Replace each AI key at the provider first, then in Railway. Anthropic: delete it under API keys in the Console. OpenAI: delete it in its project. OpenRouter: disable it before deleting, so the history stays.
3. Check for use you did not make. Anthropic Console: Usage grouped by API key, then Cost and Logs. OpenAI: Usage grouped by API key. A model you never call is the strongest signal. For OpenRouter, query the old key once.

   curl https://openrouter.ai/api/v1/key -H "Authorization: Bearer $EXPOSED_OPENROUTER_KEY"

4. Rotate databases inside the database. In Railway PostgreSQL click Regenerate on the Database tab and switch off public access under Settings and Networking. Then look for sessions you do not recognize.

   psql "$DATABASE_PUBLIC_URL" -c "SELECT pid, usename, client_addr FROM pg_stat_activity"

5. Create new tokens, set RAILWAY_TOKEN or RAILWAY_API_TOKEN in your CI secrets, reconnect GitHub and redeploy each service that reads a changed variable.

   railway redeploy --service api

6. Read your GitHub security log from 20 October and revoke apps, deploy keys and webhooks you did not add. Move funds and burn any wallet private key that was ever a variable.

What should have been in place

• Provider keys with a spend limit and an expiry. OpenRouter offers both.
• Secrets fetched at run time from a secrets manager, not kept as a long list of variables.
• A written inventory of each secret, its issuer, its owner and how to revoke it.
• Usage alerts and budget caps at every AI provider, set before an incident.
• Databases closed to the public network, as Railway's own advice says.

Questions people ask

Digiton's production review reads where your keys and secrets live and what a leak of them would let someone do, and the checks it runs are on the vibe coded app audit page.

How this brief was made: researched from the sources below, drafted with AI assistance and checked against each source on the dates shown. See the editorial policy.

Sources

1. Railway, security disclosure of 21 October, 21 October 2026, read 26 October 2026. https://blog.railway.com/p/security-disclosure-wednesday-october-21st
2. Railway, preliminary report on the 21 October security incident, 22 October 2026, read 26 October 2026. https://blog.railway.com/p/preliminary-report-october-security-incident
3. Railway status page, platform outage incident, 21 October 2026, read 26 October 2026. https://status.railway.com/incident/QH8L8B3E
4. Railway guide, check for unexpected Anthropic usage, 22 October 2026, read 26 October 2026. https://blog.railway.com/p/security-disclosure-recommendation-check-for-unexpected-anthropic-usage
5. Railway guide, check for unexpected OpenAI usage, 22 October 2026, read 26 October 2026. https://blog.railway.com/p/security-disclosure-recommendation-check-for-unexpected-openai-usage
6. Railway guide, check for unexpected OpenRouter usage, 22 October 2026, read 26 October 2026. https://blog.railway.com/p/security-disclosure-recommendation-check-for-unexpected-openrouter-usage
7. Railway guide, rotate PostgreSQL database credentials, 22 October 2026, read 26 October 2026. https://blog.railway.com/p/security-disclosure-recommendation-rotate-postgresql-database-credentials
8. Railway guide, recover failing deploys, 23 October 2026, read 26 October 2026. https://blog.railway.com/p/security-disclosure-recommendation-recover-failing-deploys
9. Aviatrix, write-up of the Railway incident as LLMjacking, 22 October 2026, read 26 October 2026. https://aviatrix.ai/threat-research-center/railway-2026-llmjacking-cloud-credential-theft-customer-secrets/

More security briefs

How these briefs are sourced and corrected. All security briefs