What happened at Railway
Railway, a PaaS platform for hosting applications, databases and services, detected anomalous activity on 21 October 2026 in the systems that store customer environment variables. According to the company, an unauthorised party may have accessed encrypted variables and, in some cases, their decrypted contents. Railway says this affects a "subset of users", but it has not given the number of accounts or explained how the intrusion happened. Even so, it recommends that all customers rotate their secrets without waiting for confirmation that their account was in scope.
The company links the incident to a series of attacks on developer platforms aimed at gaining access to AI model providers. Railway notified those providers so they could revoke keys proactively. On its side, it invalidated all Railway API tokens and is replacing storage bucket credentials. It paused builds and deployments during the investigation and on 22 October restored them in stages: Enterprise and Pro first, then Hobby, and Free and Trial last.
Why this is more serious than a typical password leak
Environment variables hold everything an application needs to run: database addresses and passwords (DATABASE_URL), AWS and GCP keys, GitHub tokens, keys for OpenAI or Anthropic, payment keys, SMTP and container registry credentials. Whoever has these values logs in to your services as your application. They need no user password and no MFA bypass. That is why the rating is high, even though Railway speaks of a subset of customers. If you use Railway for even one test project, check which secrets ended up there: they are often the same keys as in production.
What exactly to change
- Cloud keys (AWS access keys, GCP service accounts, Azure): generate new ones and delete the old ones.
- Database passwords, both for databases running on Railway itself and external ones your application connects to. In Postgres:
ALTER ROLE app_user WITH PASSWORD '...'; - Third-party API keys: AI providers, payments, mailing, SMS, CRM.
- Deployment tokens and repository access: GitHub/GitLab tokens, deploy keys, private container registry credentials.
- Railway tokens: the old ones no longer work, so CI/CD needs new ones.
- Application secrets: session and JWT signing keys, webhook secrets. Changing them logs users out, but without it someone can forge a session.
You can export each service's variables via the CLI: railway variable list --service <service> --environment <environment> --kv. Delete the output file when you are done. Order matters: generate the new secret at the provider (AWS, GitHub, AI provider), set it in Railway, deploy the application, and only then revoke the old one. If deployments on your plan are still paused and a key carries broad permissions (e.g. an AWS account administrator), revoke it immediately and accept application downtime. That costs less than someone else having access to your cloud.
How to check whether someone has already used them
- AWS: in CloudTrail, look for calls made with application keys from unknown IP addresses, new IAM users, new access keys and instances in unused regions, e.g.
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA... - GCP: Cloud Audit Logs for service accounts, new service account keys, IAM changes.
- GitHub: the organisation audit log, new deploy keys, unexpected clones and new workflows.
- Databases: connection logs from unfamiliar addresses, unusual queries exporting whole tables.
- AI providers and other APIs: the usage chart in the provider's dashboard, sudden spikes in requests outside your application's usual hours.
- Billing: cloud invoices and budget alerts. Abused keys often show up on the bill first.
Set up budget alerts if you do not have them. Railway has said it will email customers with confirmed exposure, so watch the account owner's inbox, but do not treat the absence of an email as confirmation that you are unaffected.
The same checklist for any PaaS
These steps are universal: after a similar incident at Vercel, Heroku, Render, Netlify or a CI/CD provider you do the same. Inventory the secrets, rotate at the source, deploy, revoke the old ones, review logs and bills. The longer-term lesson: environment variables on a PaaS platform are convenient but concentrate risk, because one incident at the provider exposes every key at once. What helps: least-privilege keys, separate for each environment, short-lived credentials (e.g. OIDC federation instead of long-lived AWS keys) and a secrets manager from which the application fetches values at startup. If you cannot say today which keys sit on which platform and how quickly they can be replaced, this incident is a good moment to build that inventory.