Railway Incident: Authenticated User Data Cached

Railway got pretty popular because it made the whole stack feel easy. You could deploy apps, stand up databases, wire services together, and get something real running without spending your weekend becoming a part-time cloud plumber. Railway describes itself as a full-stack cloud for deploying web apps, servers, databases, and more, and that is basically the appeal. It is slick, fast, and a lot of developers trust it with production workloads.

Then Railway stepped on a landmine.

On March 30, Railway disclosed that a configuration change accidentally enabled CDN caching on a small slice of domains that had CDN turned off. The impact window lasted from 10:42 UTC to 11:34 UTC, about 52 minutes, and Railway says the issue affected about 0.05 percent of domains on the platform with CDN disabled. During that window, cached responses could be served to someone other than the original requester, which meant one user could end up seeing content meant for another.

Railway says potentially authenticated data may have been served to unauthenticated users, and also says applications may have served requests for one user to a different user. In plain English, the cache got in the middle and started handing out somebody else’s data.

The technical root cause is ugly but straightforward. Railway says CDN caching is supposed to be opt-in. Domains without CDN enabled should route directly to the app. But a config update tied to Surrogate Keys accidentally flipped caching on for domains that had it disabled. That meant responses that should have gone back to the origin app got stored at the edge instead. If your app relied on logic to decide which user should see what, that logic could get skipped because the cache already had a response ready to serve.

Railway also said Cache-Control directives were respected where applications provided them, and Set-Cookie response headers were not cached. But that does not make this benign. Railway says most HTTP GET responses without explicit cache headers were cached by default during the incident window. So yes, this was a GET problem, not a POST free-for-all based on Railway’s public write-up. But GET is more than enough to ruin your day if your app returns user-specific dashboards, account pages, medical info, billing views, or internal admin data over cacheable GET routes.

Railway says the first signs of trouble showed up at 11:14 UTC through internal signals and user reports, and the change was fully reverted by 11:34 UTC, with cached assets purged globally. Affected users were to be notified by email. Railway also says it added more caching-behavior tests and plans to roll out CDN changes more gradually going forward.

Because the nasty part is not just that data got cached. It is that Railway turned caching on for people who had explicitly not enabled it. That means a bunch of developers had no reason to think they needed to harden every GET response for intermediary caching behavior at that moment, because according to the platform’s own model, those requests were supposed to go straight to the app. Railway’s own docs and incident report make that distinction clear.

The public reaction was exactly what you would expect. Railway’s Help Station had a dedicated incident thread, and outside discussion around the incident focused on lost revenue, user trust, and the possibility that sensitive customer data had been exposed.

So yeah, this one's gnarly. User frustration was on full display in the Railway forums. Some examples:

• “What's wrong with you folks? This is such a stupid issue. Are you out of your mind? Who asked you to enable caching for my endpoints?”

• “We just brought down our infrastructure due to this problem.”

• “We need to know urgently whether only GET or post responses were affected. The latter would mean people could have gotten other people's access tokens.”

• ‘We lost customers and revenue. We are now at risk of being sued for leaking medical data. I know you are extremely disappointed with what happened, but we need support.”

• “Day ruined? I lost years of my life. I need a vacation.”

What a tire fire.