Yesterday was a bad day for Railway. The popular cloud deployment platform — a go-to for developers who want Heroku-like simplicity without the Heroku price tag — accidentally exposed authenticated user data to unauthenticated users for nearly an hour. The culprit wasn’t a hacker. It wasn’t a zero-day. It was a single configuration change that flipped a CDN switch nobody meant to flip.

This is the kind of incident that keeps platform engineers up at night, and it’s a near-perfect case study in how infrastructure-level misconfiguration can create data exposure that application-level security controls are powerless to stop.

What Happened

On March 30, 2026, between 10:42 UTC and 11:34 UTC — a 52-minute window — Railway deployed a configuration update to their CDN provider. The intent was to enable “Surrogate Keys,” a feature that lets Railway tag and identify cached assets on a per-domain basis. Routine infrastructure work.

The problem: that configuration update had an unintended side effect. It bypassed Railway’s own logic that says “if CDN is disabled for this domain, route traffic directly to the origin.” By activating Surrogate Key support, Railway accidentally enabled CDN caching for domains that users had explicitly opted out of CDN caching.

The result was textbook Web Cache Deception territory. HTTP GET responses — including authenticated ones — were stored at edge servers globally and served back to subsequent requesters. A user logging into an application might receive a response cached from a completely different user’s session. Authenticated pages, dashboard data, profile content — whatever was cached — went to whoever asked next.

Railway’s own status page captured the urgency from affected developers: “Logging in returns another user’s session data from cache… This is a critical security incident with user data leaking between sessions.”

At 11:14 UTC, the first internal identification of a possible issue surfaced. Twenty minutes later, the configuration was fully reverted and Railway’s CDN cache was purged globally.

The Technical Root Cause

Railway’s CDN caching is opt-in. That’s an important design decision — it means developers building applications with dynamic, user-specific data can deploy on Railway without worrying that the platform will cache their authenticated endpoints. The assumption of “CDN off = no caching, ever” is a reasonable one that developers rely on.

What broke that assumption was the interaction between Surrogate Keys and Railway’s bypass logic. The Surrogate Key feature, once activated, appears to have taken precedence over the domain-level CDN disable flag. The platform’s “pass directly to origin” behavior was silently overridden.

Railway’s own post-incident write-up is admirably direct: “Domains without CDN enabled will always route requests directly to your application… During this incident, a configuration update accidentally enabled caching on domains that had it disabled.”

A few technical nuances worth noting:

  • Set-Cookie headers were NOT cached. This somewhat limits session hijacking risk via cookie theft specifically.
  • Explicit Cache-Control directives were respected. If an application was correctly setting Cache-Control: no-store or private on authenticated responses, those responses were protected.
  • Most GET responses without explicit cache headers were cached by default. This is where the real exposure lives — applications that depended on Railway’s platform-level CDN-off guarantee, and therefore never bothered setting defensive cache headers themselves.

The scope was approximately 0.05% of domains on Railway — small as a percentage, but Railway hosts millions of deployments. Reports from their community forum indicate that some affected users had medical data and financial information exposed.

Why This Class of Bug Is Dangerous

The particularly insidious thing about CDN misconfiguration incidents is that they sit below the application layer. It doesn’t matter how well your application handles authentication. It doesn’t matter if you’re using JWTs, session cookies, or OAuth. If the caching layer in front of your application decides to store and serve your responses, your app never even sees the subsequent requests.

This is the same failure mode as Web Cache Deception attacks — a class of vulnerability where attackers manipulate URLs or request paths to trick caching infrastructure into storing responses that should be dynamic and private. The difference here is that Railway itself was the actor that changed the cache behavior, without any attacker involvement.

Compare this to CVE-2024-46982, a Next.js vulnerability where a crafted HTTP request could cause a CDN to cache responses from Pages Router routes, exposing them to other users. Different mechanism, same outcome: a response the developer assumed was dynamic and private ends up as a shared, publicly-servable cache artifact.

The lesson security professionals have been preaching for years remains unresolved in practice: never rely solely on upstream infrastructure to protect authenticated content. Defense in depth means your application should be emitting the right Cache-Control headers regardless of what you believe the infrastructure in front of you is doing.

HIPAA: If any Railway-hosted application was serving protected health information (PHI) and that PHI was cached and served to unauthorized users, that is a reportable breach. Reports of medical data being exposed in Railway’s community forums make this more than theoretical.

GDPR: Serving personal data to unauthorized users is a potential Article 33 notifiable breach. Controllers — meaning Railway’s customers, not Railway itself — may have notification obligations to their supervisory authorities within 72 hours of becoming aware of a qualifying breach.

SOC 2: Railway itself has been building toward compliance credibility. This incident will be an audit finding.

PCI DSS: Any Railway-hosted application involved in payment processing needs to assess whether payment-related data or session data was in any cached responses.

The wrinkle for affected Railway customers is that they are typically the data controller, not Railway. Railway is a processor. That means the legal burden for breach notification to end users and regulators sits with Railway’s customers, not Railway.

Railway’s Response: Credit Where It’s Due

Railway’s incident handling has some genuinely good elements worth acknowledging. They published a detailed post-incident report within hours — not days. They were direct about what happened, including the specific configuration change that triggered the issue. They committed to two concrete preventative measures: additional tests for caching behavior before CDN changes reach production, and slower, shard-based CDN rollouts over hours rather than minutes.

The framing they used internally — “We’re treating this as a trust boundary violation” — is exactly the right way to categorize this. A trust boundary violation isn’t just a bug. It’s a failure of a promise the platform made to its users.

What You Should Do Right Now If You’re on Railway

1. Check if your domains were affected. Railway is sending email notifications to affected domains. If you haven’t received one, you were likely not in the 0.05%.

2. Audit your Cache-Control headers. Regardless of what caching infrastructure is in front of your application, every authenticated endpoint should be returning Cache-Control: no-store or at minimum Cache-Control: private, no-cache. Don’t rely on platform-level CDN settings as your primary cache control mechanism.

3. Review your application logs from the incident window. Look for unusual response patterns — requests answered faster than your application could have processed them, or sessions that showed cross-user data.

4. Assess breach notification obligations. If your application handles personal data, PHI, payment data, or any other regulated data category, run your breach risk assessment now. Don’t wait for Railway to tell you what you need to disclose.

5. Rotate sensitive tokens if warranted. While Set-Cookie headers weren’t cached, if your application passes authentication tokens or sensitive identifiers in response bodies or custom headers on GET requests, treat those as potentially exposed.

The Bigger Picture

This incident is a reminder that cloud deployment platforms are part of your security perimeter, even when you don’t think of them that way. When a platform like Railway, Vercel, Render, or Fly.io changes how traffic flows to your application, the impact can be immediate and material — and your application code has no visibility into it.

The appropriate posture for any application handling sensitive data is to assume the worst about the infrastructure in front of it and implement defensive headers accordingly. Cache-Control: no-store on authenticated endpoints costs nothing and breaks nothing in a properly designed application. It’s a seatbelt that protects you when the infrastructure does something unexpected.

Railway made an honest mistake, responded quickly, and was transparent about it. But the downstream impact for their customers underscores that platform-level mistakes have real-world consequences. In the cloud era, your blast radius extends to every layer of infrastructure between your code and your users.