Railway says customer environment variables may have been read, and some decrypted
Railway found suspicious activity on October 21 and says some encrypted environment variables may have been read, with values decrypted.
Railway is a hosted deployment platform: you connect a repository, and it runs the builds, pushes the releases, wires the network and stores the environment variables your services read at startup. On October 21, 2026, the company published a security disclosure signed by Jacob Cooper saying it had detected anomalous activity that morning “involving systems that store customer environment variables,” and that an unauthorized third party may have accessed encrypted variables and, for some of them, obtained the decrypted contents. Railway told every customer to rotate the variables immediately, including API keys and private registry credentials.
Key points
- The security notice arrived alongside an outage, not before it. Railway’s status page opened an investigation at 07:24 UTC on October 21, confirmed at 09:28 UTC that the dashboard, API and CLI were unavailable and builds were paused in every region, and listed builds in four regions, the API and the support site as affected. The security notice went up at 21:59 UTC; bucket credential rotation began at 22:10 UTC.
- Railway reset two kinds of credentials itself. Every bucket’s
ACCESS_KEY_IDandSECRET_ACCESS_KEYwas invalidated and regenerated, with bucket names, endpoints and stored objects unchanged. GitHub tokens Railway held for customer accounts were invalidated and the registry credentials stored on services were removed from Railway — though those registry tokens keep working on GitHub until the customer revokes them there. The October 22 redeploy guide names Faraz Patankar of the engineering team as the actor, shown in audit logs as Railway Staff. - Thirteen follow-up guides followed. A single update at 01:22 UTC on October 22 listed all 13: checking anomalous use of GCP, AWS, GitHub, Stripe, OpenAI, Anthropic, Grok and OpenRouter, rotating Redis, MySQL, MongoDB and PostgreSQL credentials, and redeploying after the bucket reset.
Background
Railway markets itself as an “all-in-one intelligent cloud provider” — the phrase on its homepage on October 22 — with the pitch that builds, deploys, networking and scaling all live in one console. The convenience comes from the same arrangement that creates the risk: customers skip running machines and configuring load balancers, and hand the platform the credentials their runtime needs. Environment variables on a platform like this are configuration and secrets at once. A database URL, a cloud access key and an AI provider’s API key often sit on the same page, injected as plaintext when the process starts.
This is not the first time Railway’s handling of incidents has drawn fire from users. On Hacker News, one commenter said they had already moved their largest customers off Railway after an earlier incident this year, and another questioned whether the company had been straight about the cause of a previous major outage. Both are user accounts, not verified reporting.
Outside coverage places the event in a sequence. TechCrunch describes OpenCode as hit by “a similar attack” earlier that week, with hackers taking more than 1% of its customers’ API keys and other secrets; OpenCode attributed it to an “AI distillation attack.” GitGuardian groups Railway with the Vercel incident in April. The same week brought PHP patches for the PHP2Shell vulnerabilities, and TechCrunch says the Railway attack appears to be separate from those.
The facts
What Railway confirmed and what it left out are easy to tell apart.
| Item | Railway’s account | Still undisclosed |
|---|---|---|
| Discovery | Anomalous activity detected “earlier this morning” on October 21; status page opened an investigation at 07:24 UTC | Exact detection time and when the intrusion began |
| What may have been reached | Systems storing customer environment variables; encrypted variables, some with values decrypted | Whether decryption came from a stolen key or a system flaw; whether sealed variables were in scope |
| Scope | Initial analysis suggests impact “may be limited to a subset of users”; confirmed accounts will be emailed | Number and list of affected accounts |
| Attack path | Not stated | Entry point, lateral movement, persistence |
| Ransom demand | Not stated | TechCrunch asked; no response at publication |
| Platform status | Deployments paused; the 17:00 UTC update on October 22 said Pro and Enterprise deployments had run normally since 06:30 UTC, Hobby and Free/Trial builds were still being restored, and a full incident report is to come | When the free tiers return |
The wording “may have accessed” deserves its own line. Cyber Security News made the distinction on October 22 that headlines tend to swallow: the notice describes possible access to encrypted variables and decrypted contents for some of them, which does not establish that attackers broke the encryption, and the notice never explains how readable values were obtained.
The platform-side actions are more concrete than the disclosure. At 20:19 UTC on October 21, Railway invalidated OAuth sessions because of impact from adjacent cache systems, signing affected users out. Bucket rotation started at 22:10 UTC, and a 22:45 UTC note told customers that audit-log entries attributed to Faraz Patankar, actor type Railway Staff, were expected. At 04:17 UTC on October 22 it invalidated every Railway API token, breaking integrations that call the public API with an old token.
Why rotation stalled
Railway told everyone to rotate at 21:59 UTC on October 21 while every build and deployment was paused. Containers read environment variables only at startup — the platform’s own redeploy guide says so — which means a new value written in the dashboard does nothing until the service restarts. Railway acknowledged as much when it listed the guides at 01:22 UTC on October 22: some steps require a redeploy and have to wait. Enterprise builds came back at 03:32 UTC, Pro builds at 06:29 UTC.
That gap became the loudest complaint on Hacker News (thread posted 21:58 UTC on October 21; 555 points and 322 comments when we checked at 17:40 UTC on October 22). Some users revoked upstream keys as advised and watched their services go down because they could not redeploy. Others chose to leave possibly exposed credentials live rather than take the site offline. Both choices cost something, and the cost comes from coupling a data-plane operation to a control-plane outage.
Sealed variables are the other detail worth knowing. Railway’s docs say a sealed value is passed to builds and deployments but never shown in the UI and cannot be retrieved through the API; railway variables and railway run do not return it either, and a sealed variable cannot be unsealed. GitGuardian notes the disclosure never says whether sealed variables were in scope, and advises rotating them too.
You can inventory what you have, but do not expect the list to be complete. The CLI documents railway variable list --service <service> --environment <environment> --kv; GitGuardian suggests redirecting that into .env.railway and running ggshield secret scan path .env.railway to see which variables still hold valid secrets. Two gaps: the CLI’s own example output prints a reference variable as a placeholder like {{SECRET_…}}, and the docs say sealed values are not returned through the CLI. What you export is a list of names and plaintext values, not every secret.
GitGuardian’s order is worth copying: revoke or rotate upstream first (AWS, GCP, GitHub, AI providers), then update the values in Railway, redeploy, verify dependent services, and delete the exported file. Upstream first, because rotating a copy on the platform while the old key still works accomplishes nothing.
What others say
TechCrunch (Zack Whittaker, October 22) confirms Railway advised all users to revoke and rotate private keys, and notes the company did not say how many customers were affected or what the root cause was, and did not immediately answer questions about the incident or a ransom demand. It places the breach next to OpenCode and separates it from PHP2Shell.
GitGuardian’s October 22 brief, credited to its cybersecurity research team, runs about two minutes and does no forensics: no affected-user count, no scan results. What it adds is generic response order — upstream first, scan the exported file to decide what to rotate first — rather than a finding specific to this breach.
Railway’s own attribution is that this is part of a series of attacks on platform companies aimed at compromising AI inference providers, and that it notified those upstream providers to revoke keys proactively. On Hacker News, commenters asked whether that sentence was an accusation aimed at competitors, and objected that “the attacker used AI” is not a substitute for maintaining a secure system. The attribution currently has no supporting detail.
Cyber Security News (Guru Baran, October 22) mostly restates the official notice, but keeps “may have accessed” separate from “confirmed leak,” which is more careful than most headlines.
Hacker News users supplied the closest thing to ground truth, and their claims need the most discount. One said an OpenRouter key had been used for roughly $2 of Opus 5.5 and Fable calls. Another said an Anthropic key was disabled on evidence of abuse about three hours after the Railway notice arrived, after roughly $20 of Opus 4.8 tokens. A third described seeing Railway staff reset bucket credentials while reviewing logs. These are self-reports, unverified, and not a measure of the incident’s scope.
Our take
If your team runs on Railway, treat this as a credential exposure and keep the hedging intact. Three things are established: a third party reached systems that store environment variables; the company acted on the worst case by resetting every bucket credential and the GitHub tokens it held; the attack path and confirmed scope remain unpublished.
The lesson worth keeping is that rotation has to work independently of the deploy pipeline. When builds stop, credentials cannot be changed, and a service either keeps running on an old secret or goes down with a new one. Teams that keep critical credentials in their own cloud key management and fetch them at startup at least have a path around the platform’s control plane.
The sequence to follow: revoke and reissue upstream, export and scan the variable list to see what still holds valid secrets, update the values in Railway, redeploy, verify dependent services, delete the local dump. Buckets and GitHub need an extra step; only the customer can mint a new GitHub token.
In incidents like this, stolen credentials are the opening move. The LiteLLM 1.107.0 release chain compromise showed how an attacker with tokens rewrites a release process, and the PingCAP intrusion showed how customer metadata and credentials accumulate on a vendor’s side as a map. Railway sits between the two: a platform holding secrets for its customers, where the only customer-side response to possible exposure is rotation and log review.
Four things are still outstanding: the full incident report, the number of affected accounts, whether sealed variables were in scope, and whether a ransom demand was made. The status page says a full report will follow on the blog once the incident is resolved. Until then, any number for how many customers were hit is a guess.