.svg)
Truvo Incident Tracker
Railway security incident: customer environment variables
On October 21, 2026, Railway disclosed that an unauthorized party accessed customers' encrypted environment variables and decrypted some of them. This page tracks what is confirmed, what is still unknown, and what customers should do, with each fact dated and sourced.
Talk to incident response
Share what happened and a consultant will follow up to book a call.
Railway incident key facts
| Disclosed | October 21, 2026, on the Railway blog and status page |
| What was accessed | Encrypted customer environment variables. Decrypted contents for a subset of customers |
| Railway's response | Paused builds and deployments. Invalidated Railway API tokens and the GitHub tokens it held. Rotated bucket credentials. Asked upstream providers to revoke keys |
| Builds | Resuming in stages: Enterprise first, then Pro, Hobby, Free and Trial |
| Root cause and scope | Not disclosed. Postmortem promised |
| Railway's attribution | Part of a series of attacks on platform companies aimed at compromising AI inference providers |
What is confirmed and what is still unknown about the Railway incident
Confirmed
- An unauthorized party accessed encrypted environment variables and decrypted some of them (Railway disclosure)
- Railway invalidated all Railway API tokens and the GitHub tokens it held, rotated S3-compatible bucket credentials, and invalidated OAuth sessions (Railway status page)
- Railway tells every customer to rotate all environment variables, API keys and private registry credentials and to review logs (Railway disclosure)
- Railway published rotation guides for Redis and other databases, xAI/Grok keys, and buckets and GitHub (Railway blog)
- Railway will email the customers it confirms were affected (Railway disclosure)
Not yet known
- How the attacker got in, and how long they had access
- How many customers, and which plans or regions, were affected
- Whether sealed or shared variables were included
- Whether volumes, databases, source code or logs were accessed (Railway has made no statement either way)
- Which upstream providers revoked keys, and whether any key was misused. Claims of stolen AI keys being resold are unverified
- Any link to the OpenCode Console breach of October 16-17 (unverified)
What Railway customers should do, step by step
The steps follow the NIST SP 800-61 incident response phases. Detection and analysis and containment start together: rotate each secret as soon as it is on the inventory, and read its usage logs while the next one is rotated.
1. Detection and analysis
- Open an incident record with an owner and a decision log
- Export every variable from every project and service, including shared variables, and rank by blast radius
- Pull usage logs at each provider for the exposed keys and look for unfamiliar IPs, models or volumes
- Make the breach determination for each law that applies, notify where required, and notify customers whose contracts require it
2. Containment
- Revoke and reissue each secret at its issuer, database and cloud credentials first, then update Railway
- Regenerate Railway-managed database credentials and remove unneeded public TCP proxies
- Revoke GitHub registry tokens on GitHub
3. Eradication and recovery
- Remove anything created with the exposed credentials: database users, API keys, webhooks, IAM users
- Reconnect GitHub and redeploy every service once builds resume
- Confirm services work with the new secrets and the old ones are rejected
4. Post-incident activity
- After Railway's postmortem, run a lessons-learned review and update Railway's vendor risk assessment
- Shorten secret lifetimes with workload identity, short-lived credentials or a secrets manager
Railway incident obligations under SOC 2, ISO 27001, GDPR, HIPAA and Canadian privacy law
The Railway incident is a security incident for every affected customer. It becomes a breach under privacy law only when exposed secrets led to personal data or PHI being compromised, or the logs cannot rule that out.
| Framework or law | When it applies | What it asks for | Clock |
|---|---|---|---|
| SOC 2 Framework | Supplier incident affecting in-scope systems | Evaluate and respond (CC7.3-CC7.5), vendor risk review (CC9.2), external communication (CC2.3) | None set by SOC 2. Your policy and customer contracts |
| ISO 27001:2022 Framework | Supplier incident affecting in-scope systems | Supplier and cloud controls (A.5.19-A.5.23), incident management and evidence (A.5.24-A.5.28) | None set by ISO. Your procedure |
| GDPR Law | Exposed secrets led to personal data being compromised | Notify the supervisory authority unless unlikely to result in risk. Tell individuals if high risk. Document every breach. Processors notify controllers without undue delay | 72 hours from reasonable certainty of a breach |
| HIPAA Law | Access to credentials is a security incident. PHI accessed is a presumed breach | Document incidents. Four-factor risk assessment. Notify individuals, HHS and media as required. Business associates notify covered entities | Within 60 days of discovery |
| PIPEDA Law | Breach of security safeguards with real risk of significant harm | Report to the OPC and notify individuals. Record every breach | As soon as feasible. Keep records 24 months |
| Quebec Law 25 Law | Confidentiality incident with risk of serious injury | Notify the CAI and affected people. Register every incident | Promptly |
Working through the Railway rotation?
Truvo's incident response team runs the secret inventory, the log review and the breach determination with you, and leaves the evidence your auditor and customers will ask for.
Railway incident: questions and answers
Yes. Railway tells every customer to rotate all environment variables, API keys and registry credentials, and the number of affected accounts is not public. Revoke each secret at the provider that issued it, then update Railway and redeploy.
It is a security incident for every affected customer from day one. It becomes a personal-data breach only if exposed credentials led to personal data or PHI being accessed, or the logs cannot rule that out. The log review at each provider decides it.
GDPR's 72-hour clock starts when you have a reasonable degree of certainty that personal data was compromised, not when Railway disclosed. If Railway is your processor, it must notify you without undue delay. Document every breach, including those that need no notification.
Unauthorized access to credentials for systems holding PHI is a security incident under 45 CFR 164.304. If PHI was accessed, HIPAA presumes a breach unless a four-factor risk assessment shows low probability of compromise, and individuals must be notified within 60 days of discovery.
Neither sets a deadline. Both expect a documented incident response, communication as appropriate, and an updated vendor risk assessment. Notification duties come from customer contracts and privacy laws.
Railway's regions are California, Virginia, Amsterdam and Singapore. Teams that promised Canadian data residency should check whether those promises hold for data stored on Railway.
Sources
- Railway: Security Disclosure, Wednesday October 21st (Oct 21, 2026)
- Railway: rotate Redis database credentials (Oct 22, 2026)
- Railway: check for unexpected Grok usage (Oct 22, 2026)
- Railway: redeploy buckets and reconnect GitHub (Oct 22, 2026)
- Railway status page (checked Oct 22, 2026, 04:00 UTC)
- Railway regions documentation (checked Oct 22, 2026)
Change log
- Oct 22, 2026, 12:46 UTC: Timestamp review. No new information from Railway since the 04:00 UTC update.
- Oct 22, 2026: Tracker published. Facts as of 04:00 UTC.