Railway Security Incidents 2026: Four Failures in Six Weeks — What EU Developers Need to Know

In Q1 2026, Railway — one of the most popular developer PaaS platforms — experienced four security and reliability incidents in six weeks. Individually, each incident had a technical explanation. Together, they reveal a structural pattern that EU developers building GDPR-regulated applications should take seriously.

This post documents the incidents, explains their legal significance under GDPR, and outlines what EU-native infrastructure alternatives exist.

The Incidents: A Q1 2026 Timeline

March 30: CDN Caching Bug — Authenticated Data Served to Other Users

This is the most serious incident from a GDPR perspective.

At 10:42 UTC on March 30, Railway deployed a configuration change to enable Surrogate Keys. The change inadvertently activated HTTP caching on approximately 0.05% of domains that had previously disabled CDN caching. For a 52-minute window — until 11:34 UTC — authenticated responses were cached and served to different users.

Approximately 3,000 users were affected. While Railway's postmortem notes that Set-Cookie headers were not cached, GET responses without explicit cache headers were returned to users who were not the original requester. In practice: if your application served an authenticated response (a dashboard, a user's settings page, a document list) without explicit Cache-Control: no-store headers, another user requesting the same URL could have received your user's response.

Railway reverted the change and purged the global cache by 11:34 UTC. The 52-minute exposure window was stopped. But the incident happened.

GDPR Article 32 significance: Article 32 requires controllers and processors to implement "appropriate technical and organisational measures to ensure a level of security appropriate to the risk", including measures to ensure ongoing confidentiality and integrity of processing systems. A CDN misconfiguration that serves authenticated user data to unauthenticated users is a textbook Art. 32 failure — not because Railway is negligent, but because configuration changes at the infrastructure level can silently break the confidentiality guarantee your application depends on.

February 18–21: DDoS Attack + Cloudflare Outage — Compounding Failures

On February 18 at 3:57 UTC, Railway experienced a significant DDoS attack. The team deployed Fastly WAF as mitigation. Then on February 20, just as the mitigation was taking effect, Cloudflare suffered its own unrelated global outage at 17:48 UTC — triggered by a BGP configuration error that withdrew Railway's IP prefixes from the routing table.

The result: Railway customers who had weathered two days of DDoS disruption then faced a compounding failure from their CDN provider. The combination of a targeted attack and an unrelated third-party failure is, objectively, bad luck. But it illustrates a broader point: when your infrastructure depends on multiple US-headquartered vendors in a chain (Railway → Cloudflare → your application), any link in that chain can cause downtime for European users.

January 28–29: GitHub OAuth Rate Limit Failure — Logins Broken

Railway's authentication flow relies on GitHub OAuth. On January 28–29, GitHub's OAuth infrastructure hit rate limit exhaustion that prevented new logins to Railway. Users who needed to log in to manage deployments, roll back a bad release, or check logs during an incident could not access the platform.

This type of dependency coupling — where your PaaS login depends on a third-party OAuth provider's uptime — is a design decision with availability implications. EU developers operating under SLA commitments or incident response requirements found themselves locked out of their own infrastructure.

March: OAuth Device Flow Attack — Railway IPs Used Against Microsoft 365 Users

From March 2 through March 30, threat actors exploited the OAuth device flow to target Microsoft 365 identities across 340+ organizations. The attack infrastructure ran partly from Railway IP addresses. Railway's own customer workloads were not compromised — the platform was being abused by malicious actors who deployed attack tooling as legitimate Railway projects.

The GDPR implication here is indirect but real: if your application is hosted on Railway, your users' requests originate from IP ranges shared with attack infrastructure. IP reputation monitoring, SIEM systems, and security filters increasingly flag Railway-originating IPs due to this abuse. That may affect email deliverability, API access, and fraud detection systems for applications hosted on the platform.

The Structural Issue: Railway Is Not an EU-Native Platform

These incidents have technical explanations. What they collectively reveal is a structural observation: Railway is a US-headquartered company (San Francisco, California) operating shared infrastructure that EU developers depend on for GDPR-regulated workloads.

This matters for three reasons:

1. No EU data residency by default. Railway does not offer a dedicated EU-only region. Your application data, logs, and deployment metadata live on US-headquartered infrastructure. Railway supports GDPR via Standard Contractual Clauses (SCCs) in its Data Processing Addendum — but SCCs are a legal instrument for authorizing data transfers, not a substitute for data staying in the EU. Post-Schrems II, the adequacy of SCCs for US-headquartered providers remains a live legal question in several EU member states.

2. CLOUD Act exposure. Railway Inc. is a US company. Under the CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018), US authorities can compel US companies to hand over data stored on their infrastructure — including data stored in EU data centers — without going through the standard EU mutual legal assistance process. This is a structural exposure that no contractual DPA clause can eliminate.

3. Art. 32 compliance requires infrastructure trust. The March 30 CDN incident illustrates that Art. 32 compliance is not just about your application's security measures — it is about trusting that the infrastructure layer beneath your application maintains confidentiality guarantees. A CDN misconfiguration at the platform level broke that guarantee for 52 minutes without any action by affected developers.

What "EU-Native" Actually Means

The term gets used loosely, so here is a precise definition: an EU-native PaaS is one where (a) the operating entity is incorporated under EU law, (b) infrastructure operates exclusively in EU-jurisdiction data centers, and (c) no US-headquartered company in the infrastructure chain has CLOUD Act obligations that could reach your data.

This excludes AWS EU Regions (Amazon is a US company), Railway with EU deployments (Railway Inc. is a US company), and Cloudflare R2 with EU storage classes (Cloudflare Inc. is a US company).

It includes providers incorporated in Germany, France, the Netherlands, or other EU member states, operating on infrastructure from Hetzner, Scaleway, OVHcloud, or equivalents.

Comparison: Railway vs. EU-Native PaaS

What EU Developers Should Do

If you are building an application subject to GDPR — which means any application serving EU users, regardless of where you are based — the March 30 Railway incident is a concrete example of what Art. 32 compliance demands at the infrastructure level:

1. Require EU-incorporated hosting. Not "EU data center with US company". EU-incorporated.
2. Use infrastructure with no CLOUD Act chain. Every US-headquartered company in your infrastructure chain is a potential CLOUD Act vector.
3. Default to explicit Cache-Control: no-store on authenticated responses. This is good practice regardless of your PaaS provider, but the Railway incident demonstrates why the platform's CDN behavior matters.
4. Document your processing chain under Art. 30. If Railway is your processor, the March 30 incident is a data breach notification event for affected controllers — Art. 33 requires notification to supervisory authorities within 72 hours of becoming aware.

sota.io: EU-Native Developer PaaS

sota.io is a developer PaaS incorporated under EU law, running exclusively on EU infrastructure. Deploy Node.js, Python, Next.js, Go, or any containerized application with one command. Managed PostgreSQL included. GDPR-compliant by design — no SCCs, no CLOUD Act exposure, no US-headquartered company in the chain.

sota deploy
# → Deployed to EU infrastructure in 45 seconds
# → Managed PostgreSQL auto-provisioned
# → GDPR DPA included, EU-incorporated processor

Free tier available. Start deploying to the EU.

Sources: Railway incident reports published at blog.railway.com (March 30 CDN caching incident, February 18–21 DDoS/Cloudflare outage, February 11 abuse detection incident, Q1 2026 OAuth device flow campaign). Railway compliance documentation at docs.railway.com/enterprise/compliance.