Railway-Sicherheitsvorfall: Warum die Haftung bei 100 Dollar endet

Am 21. Oktober 2026 hat der US-Hostinganbieter Railway seinen Kunden mitgeteilt, dass ein unbefugter Dritter womöglich auf die gespeicherten Umgebungsvariablen zugegriffen und einen Teil davon entschlüsselt hat. In diesen Variablen liegen die Schlüssel zu fast allem, was eine Anwendung braucht: Datenbankzugänge, Zahlungsanbieter, KI-Dienste, Cloudkonten. Railway rät allen Kunden, sämtliche Variablen auszutauschen, und hat die Builds stundenlang gestoppt. Eine Entschädigung bietet das Unternehmen nicht an. Seine Nutzungsbedingungen begrenzen die Haftung auf 100 Dollar oder die Entgelte der letzten zwölf Monate, je nachdem, was höher ist; Betriebsunterbrechung und Datenverlust sind ganz ausgeschlossen. Auch Cryptoticker.io, eines meiner Unternehmen, ist Railway-Kunde und hat die Mail bekommen. Meine Einordnung als Unternehmer: Wer heute Software betreibt, legt seine wertvollsten Geheimnisse bei Plattformen ab, die für fast nichts einstehen. Das ist ein Risiko für die digitale Infrastruktur, und die Politik muss es endlich so behandeln.

Stand: 22. Oktober 2026, 15:00 Uhr.

Mehr zum Thema: KI im Gründeralltag, mit Grundlagen, Praxis und allen Artikeln an einer Stelle.

Railway-Sicherheitsvorfall: Was am 21. Oktober passiert ist

Railway ist eine Plattform, auf der Entwickler und Firmen ihre Anwendungen, Datenbanken und Hintergrunddienste betreiben, ohne sich um Server zu kümmern. Das Unternehmen aus San Francisco wurde 2020 gegründet, sammelte im Januar 2026 in einer Finanzierungsrunde 100 Millionen Dollar ein und nennt mehr als zwei Millionen Entwickler als Nutzer (Railway zur Series B). Für Europa betreibt es eine Region in Amsterdam.

Am Morgen des 21. Oktober meldete die Statusseite zunächst einen Plattformausfall. Dashboard, Schnittstelle und Kommandozeile fielen aus, neue Builds wurden in allen Regionen gestoppt. Erst am Abend kam der eigentliche Grund ans Licht. In einer Sicherheitsmeldung von Gründer Jake Cooper heißt es, Railway habe anomale Aktivität an den Systemen entdeckt, die Umgebungsvariablen der Kunden speichern. Ein unbefugter Dritter habe womöglich auf die verschlüsselten Variablen zugegriffen und bei einem Teil davon die entschlüsselten Inhalte erlangt (Sicherheitsmeldung von Railway). Railway hält das für Teil einer Serie von Angriffen auf Plattformfirmen, deren Ziel die Anbieter von KI-Diensten seien.

Was Railway nicht sagt: wie die Angreifer hineinkamen, wann genau der Zugriff erkannt wurde und welche Kunden betroffen sind. Die Meldung spricht von einer Teilmenge, rät aber allen, sämtliche Variablen samt API-Schlüsseln und Zugangsdaten zu Container-Registries auszutauschen und die Protokolle zu prüfen. Am Morgen des 22. Oktober um 04:17 Uhr UTC machte Railway zudem alle eigenen API-Tokens der Kunden ungültig (Statusseite des Vorfalls).

Die Kundenmail von Railway im Wortlaut

Bei uns kam die Mail am 21. Oktober um 22:37 Uhr UTC an, in deutscher Zeit also um 00:37 Uhr in der Nacht zum Donnerstag. Absender war der Railway-Support, Betreff „Urgent: Railway Security Disclosure - Rotate Credentials“. Der Inhalt entspricht der Sicherheitsmeldung im Blog: anomale Aktivität, möglicher Zugriff auf verschlüsselte und teils entschlüsselte Variablen, Verdacht auf eine Angriffsserie gegen KI-Anbieter. Danach drei Anweisungen: alle Variablen sofort widerrufen und neu ausstellen, Zugangsdaten zu externen Registries prüfen, Protokolle durchsehen. Und der Hinweis, dass bis zur Wiederherstellung der Builds keine neuen Versionen ausgerollt werden können.

Drei Dinge fallen auf. Erstens bricht der zweite Handlungspunkt mitten im Satz ab: Was Kunden mit Zugangsdaten zu externen Registries tun sollen, steht dort nicht. Zweitens enthält die Mail kein Wort zu einer Entschädigung, zu Gutschriften oder zu einem Ansprechpartner für Schäden. Drittens kam sie Stunden nach den ersten Folgen. Der Dienst Postiz hatte schon um 21:11 Uhr UTC für alle Kunden abgeschaltet, weil Anthropic und Stripe ihm kompromittierte Schlüssel gemeldet hatten, wie sein Gründer auf X schrieb (Beitrag von Postiz-Gründer Nevo David). Die Mail selbst ist sachlich und klar in der Anweisung. Was fehlt, ist alles, was einem Kunden beim Abschätzen des eigenen Schadens hilft.

Chronik des Railway-Vorfalls

Die Statusseite listet bis zum Mittag des 22. Oktober 42 Einträge. Die wichtigsten Zeitpunkte, alle in UTC, also zwei Stunden vor deutscher Sommerzeit:

Zwischen dem ersten Statuseintrag und dem Hinweis auf den Sicherheitsvorfall lagen 14 Stunden und 35 Minuten. Ob Railway den Angriff schon früh erkannt oder erst im Lauf des Tages verstanden hat, lässt sich von außen nicht sagen. Für die Kunden heißt es in beiden Fällen dasselbe: Ein ganzer Arbeitstag verging, in dem sie weder wussten, dass ihre Schlüssel in Gefahr waren, noch neue Versionen ausrollen konnten. Kleine Kunden auf den günstigen Tarifen warteten mehr als 27 Stunden auf ihre Builds.

Warum Umgebungsvariablen bei Railway so wertvoll sind

Umgebungsvariablen sind die Stelle, an der eine Anwendung ihre Geheimnisse findet. Die Datenbank verlangt ein Passwort, der Zahlungsanbieter einen geheimen Schlüssel, der KI-Dienst ein Token, das Mailsystem eine Anmeldung. Auf Plattformen wie Railway trägt man diese Werte in eine Oberfläche ein, und sie werden beim Start in die Anwendung gereicht. Das ist bequem und üblich. Es bedeutet aber auch: Wer diesen Speicher öffnet, hält die Generalschlüssel Tausender Firmen gleichzeitig in der Hand.

Railways eigener Hinweis, die Angreifer hätten es auf KI-Anbieter abgesehen, passt zu einem Muster, das seit zwei Jahren wächst. Sicherheitsforscher von Sysdig gaben ihm 2024 einen Namen: LLMjacking, das Kapern fremder Zugänge zu Sprachmodellen. In ihren Fällen beliefen sich die Kosten für ein Opfer auf über 46.000 Dollar am Tag, mit teureren Modellen auf über 100.000 Dollar (Sysdig zu LLMjacking). Anthropic beschreibt in seinem Bedrohungsbericht vom September 2026, dass für mehrere kriminelle Gruppen gestohlene KI-Schlüssel inzwischen das eigentliche Ziel sind; verkauft wird über Zwischenhändler an Netze, die billigen Zugang zu Spitzenmodellen anbieten (Anthropic, Bedrohungsbericht September 2026).

Railway steht damit nicht allein. Im April 2026 meldete Vercel, dass Angreifer über ein Drittwerkzeug eingedrungen waren und nicht als sensibel markierte Umgebungsvariablen von Kunden ausgelesen hatten (Vercel-Sicherheitsbulletin). Der asiatische Anbieter Zeabur wurde im August und im Oktober angegriffen, beim zweiten Mal suchte der Angreifer gezielt nach Schlüsseln für KI-Dienste (Zeabur zum Vorfall im Oktober). Am 21. Oktober, demselben Tag wie bei Railway, stand auf dem Python-Paketverzeichnis für knapp zwei Stunden eine verseuchte Fassung der weit verbreiteten KI-Bibliothek LiteLLM, die genau solche Schlüssel abgriff (Wiz zu LiteLLM). Ob hinter allen Fällen dieselben Täter stecken, ist nicht belegt. Das Muster ist es: Wer Schlüssel vieler Kunden bündelt, wird zum Ziel.

Für Krypto-Unternehmen kommt eine zweite Ebene dazu. Viele Handelsbots und Dienste halten private Wallet-Schlüssel oder Börsenschlüssel in denselben Variablen. Die Sicherheitsforscherin Taylor Monahan zählte ab 19:36 Uhr UTC über 500 Transaktionen von mehr als 200 Adressen auf mindestens 19 Blockchains, zusammen rund 371.000 Dollar, und ordnet sie Schlüsseln aus Railway zu (Taylor Monahan auf X). Railway hat diesen Zusammenhang nicht bestätigt. Auffällig ist der Zeitpunkt: Die Abflüsse begannen gut zwei Stunden vor der öffentlichen Warnung.

Railway-Haftung: Was die Nutzungsbedingungen ausschließen

Die kurze Antwort: fast alles. Die Nutzungsbedingungen von Railway in der Fassung vom 20. April 2026 schließen indirekte Schäden und Folgeschäden jeder Art aus, ausdrücklich auch entgangenen Gewinn, Betriebsunterbrechung, Datenverlust, Arbeitsausfall und den Verlust von Ansehen. Für alles andere gilt eine Obergrenze, im Original „THE GREATER OF (I) ONE-HUNDRED ($100) DOLLARS OR (II) THE AMOUNTS PAID AND/OR PAYABLE“, also 100 Dollar oder die in den zwölf Monaten vor dem Anspruch gezahlten Entgelte, je nachdem, was höher ist (Railway Terms of Service).

Eine Ausnahme für Vorsatz, grobe Fahrlässigkeit oder den Bruch der Vertraulichkeit enthält die Klausel nicht. Die Dienste werden ohne jede Gewähr erbracht, ausdrücklich auch ohne Zusage, dass sie ununterbrochen oder fehlerfrei laufen. Der Kunde stellt Railway sogar von Ansprüchen frei, die mit der Nutzung seines Kontos durch Dritte zusammenhängen. Und er verpflichtet sich, seine Zugangsdaten selbst zu schützen. Eine eigene Sicherheitszusage für die gespeicherten Geheimnisse steht in den Nutzungsbedingungen nicht.

Wer hofft, das sei eine neue Verschärfung, irrt. Ein Vergleich der archivierten Fassungen in der Wayback Machine zeigt: Die Haftungsklausel steht wortgleich schon in den Bedingungen vom 25. September 2021 und vom 14. März 2024. Die Neufassung vom April 2026 hat vor allem die Rechte an Kundeninhalten neu geregelt und den Vertrag zur Auftragsverarbeitung einbezogen. Die 100 Dollar sind also kein Kniff aus diesem Frühjahr, sondern Geschäftsgrundlage seit Jahren, und kaum ein Kunde hat sie je gelesen.

Selbst der große Enterprise-Vertrag nimmt die Verletzung der Datensicherheit ausdrücklich aus dem Schadensersatz heraus (Railway Enterprise Agreement, Abschnitt 11). Verstößt Railway gegen seine Sicherheitspflichten und bessert nicht binnen 30 Tagen nach, bleibt dem Kunden nach Abschnitt 4 als einziger Rechtsbehelf die Kündigung. Der Vertrag zur Auftragsverarbeitung verspricht vernünftige Schutzmaßnahmen, unterwirft aber alle Ansprüche daraus der Obergrenze des Hauptvertrags (Railway Data Processing Addendum).

Zum Vergleich, wie Railway sonst mit Ausfällen umgeht: Nach einer Angriffswelle mit Überlastung im Februar 2026 kündigte das Unternehmen eine Entschädigung an (Vorfallbericht vom Februar 2026). In der Sicherheitsmeldung vom 21. Oktober und auf der Statusseite kommen die Worte Gutschrift, Entschädigung oder Erstattung nicht vor. Gerade bei einem Vorfall, der an die Geheimnisse der Kunden geht, bleiben sie mit ihrem Aufwand allein.

Wer nach deutschem Recht für den Railway-Schaden haften würde

Nach deutschem Recht hätte die Railway-Klausel schlechte Karten. Haftungsbeschränkungen in Allgemeinen Geschäftsbedingungen sind unwirksam, wenn sie den Vertragspartner unangemessen benachteiligen (§ 307 BGB). Schließt eine Klausel die Haftung für grobe Fahrlässigkeit aus, wertet der Bundesgerichtshof das auch zwischen Unternehmen als Indiz für eine solche Benachteiligung (Urteil vom 19. September 2007, VIII ZR 141/06). Eine Höchstsumme muss außerdem den vertragstypischen Schaden abdecken, und von den Hauptpflichten eines Vertrags darf sich niemand freizeichnen. Für einen Hoster gehört die sichere Verwahrung der Kundengeheimnisse zu genau diesen Pflichten.

Auch der Aufwand, den Kunden jetzt haben, wäre nach deutschem Schadensrecht grundsätzlich ersatzfähig. Der Bundesgerichtshof hat 2008 entschieden, dass die Arbeitszeit eigener Mitarbeiter ersetzt werden kann, wenn sie der Schadensbeseitigung selbst dient und nicht nur der Ermittlung oder Abwicklung des Anspruchs (Urteil vom 9. Dezember 2008, VI ZR 173/07, Randnummer 23, Volltext bei Lexetius). Das Austauschen von Schlüsseln, das Neuaufsetzen von Verbindungen und das Prüfen der Protokolle wären solche Arbeiten.

Der Haken: Deutsches Recht gilt hier gar nicht. Railway hat das Recht des US-Bundesstaats Delaware gewählt, und zwischen Unternehmen ist diese Wahl nach Artikel 3 der europäischen Rom-I-Verordnung wirksam. Die AGB-Kontrolle, die deutsche Mittelständler vor solchen Klauseln schützt, endet an der Rechtswahl. Gestritten wird in einem Einzelschiedsverfahren in San Francisco, Sammelklagen sind ausgeschlossen. Für eine Firma mit einem Schaden von ein paar tausend Euro ist das praktisch das Ende der Geschichte.

Etwas anders sieht es beim Datenschutz aus. Liegen in einer betroffenen Datenbank personenbezogene Daten, ist der Railway-Kunde der Verantwortliche. Er muss innerhalb von 72 Stunden prüfen und gegebenenfalls die Aufsichtsbehörde informieren (Art. 33 DSGVO). Gegenüber betroffenen Personen haften Kunde und Railway gemeinsam für den ganzen Schaden (Art. 82 Abs. 4 DSGVO), eine Vertragsklausel zwischen beiden bindet die Betroffenen nicht. Im Verhältnis zwischen Kunde und Railway greift dann aber wieder die Obergrenze. Wichtig: Dieser Abschnitt ist meine Einordnung als Unternehmer, keine Rechtsberatung.

PHP2Shell: Die zweite kritische Lücke derselben Woche

Am selben 21. Oktober erschienen die Sicherheitsupdates für PHP2Shell, zwei Lücken in der Programmiersprache PHP mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Beide erreichen 9,2 von 10 Punkten im Bewertungssystem CVSS 4.0 und erlauben es, ohne Anmeldung fremden Code auf einem Webserver auszuführen. Behoben sind sie in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 (Ankündigung auf php.net). Für PHP 8.1 und ältere Versionen gibt es kein offizielles Update mehr, nur Quellcode-Korrekturen für Fachleute.

Das Bundesamt für Sicherheit in der Informationstechnik stufte die Lage als orange ein und riet, Systeme vorübergehend vom Internet zu trennen, wenn sich das Update nicht sofort einspielen lässt (BSI-Cybersicherheitswarnung). Die US-Behörde CISA und das FBI rieten dasselbe (CISA-Warnung). Das Sicherheitsunternehmen watchTowr beobachtet die Ausnutzung seit dem 21. Oktober in seinen Fallen für Angreifer (watchTowr zu PHP2Shell).

Wie groß die Angriffsfläche ist, zeigt eine Auswertung des Sicherheitsdienstes Mallory auf Basis der Suchmaschine Shodan: Von 2,6 Millionen PHP-Diensten im Internet, die ihre Version verraten, laufen 73,5 Prozent auf PHP 8.1 oder älter. In Deutschland sind es 100.805 von 175.443, also 57 Prozent (Mallory zur PHP-Lücke). Wer dort betroffen ist, kann nicht einfach ein Update einspielen, sondern muss erst auf eine unterstützte Version wechseln.

Mit Railway hat PHP2Shell technisch nichts zu tun. Zusammen zeigen beide Vorfälle aber, wie dünn die Schicht geworden ist, auf der unsere Geschäfte laufen. Wir haben am 21. und 22. Oktober unsere eigenen PHP-Seiten durchgemessen. Die wichtigste Erkenntnis für alle, die bei einem klassischen Webhoster liegen: Bei uns kam der Fix vom Hoster innerhalb der eingestellten Hauptversion. Wer in Panik im Verwaltungsmenü die PHP-Version umstellt, gewinnt keine Sicherheit, riskiert aber eine kaputte Seite. Erst messen, welche Version wirklich läuft, dann handeln.

KI verkürzt die Zeit zwischen Lücke und Angriff

Bei PHP2Shell war künstliche Intelligenz auf beiden Seiten im Spiel. Gefunden haben die Lücken die Sicherheitsfirma Calif im Rahmen eines Programms von OpenAI und unabhängig davon das Unternehmen Wiz, das nach eigenen Angaben mit den Modellen Gemini 4 Argon und GPT-5.6 Sol arbeitete. Ein einzelner Forscher habe so in einer Woche geschafft, wofür früher ein Spitzenteam Monate gebraucht hätte (Wiz zu PHP2Shell). Das BSI schreibt in seiner Warnung, Angreifer könnten mit KI-Werkzeugen Patches in kurzer Zeit analysieren und daraus Angriffe bauen.

Die Zahlen dazu sind deutlich. Google Mandiant schätzt die mittlere Zeit bis zur Ausnutzung einer Lücke in seinem Bericht M-Trends 2026 auf minus sieben Tage: Angegriffen wird im Schnitt, bevor der Patch erscheint. Für 2018 und 2019 lag der Wert noch bei 63 Tagen (Google Mandiant, M-Trends 2026). Der Dienst VulnCheck zählte im ersten Halbjahr 2026 fast jede vierte ausgenutzte Lücke, nämlich 23,43 Prozent, schon am Tag ihrer Veröffentlichung oder davor als ausgenutzt (VulnCheck, erstes Halbjahr 2026).

Ein Wort zu den Schlagzeilen: Ein Newsletter titelte am 22. Oktober „AI hacks 70% of internet“. Dahinter steckt keine Studie. Die 70 Prozent beschreiben den Anteil von PHP an Websites, deren Serversprache bekannt ist, nach W3Techs sind es 69,3 Prozent (W3Techs zu PHP). Gehackt wurden diese Seiten nicht, und gefunden hat die Lücken die KI der Verteidiger. Die nüchterne Botschaft ist ernst genug: Das Fenster zwischen Fund und Angriff schließt sich, und wer seine Updates nicht in Stunden einspielt, wird zum leichten Ziel.

Wohin das führt, weiß heute niemand genau. Dieselben Modelle, die Lücken in Tagen statt Monaten finden, stehen Angreifern offen, und gestohlene Zugänge zu diesen Modellen sind selbst zur Beute geworden. Für Unternehmen heißt das: Die Arbeitsweise der letzten zehn Jahre, alles bei einem bequemen Anbieter abzulegen und sich auf dessen Sorgfalt zu verlassen, passt nicht mehr zu diesem Tempo.

Railway-Kunden: Was Ihr jetzt tun solltet

Jeder Schlüssel, der in einer Umgebungsvariable bei Railway lag, gilt als bekannt, bis das Gegenteil belegt ist. Austauschen heißt dabei nicht, in Railway einen neuen Wert einzutragen. Ausgetauscht wird beim Aussteller, also bei der Datenbank, beim Zahlungsanbieter, beim KI-Anbieter. Erst wenn der alte Schlüssel dort gesperrt ist, ist er wertlos.

1. Bestand aufnehmen. Alle Projekte und Umgebungen durchgehen und jede Variable einem Aussteller zuordnen: Datenbank, Cache, Speicher, Zahlungsdienst, Mailversand, KI-Anbieter, Container-Registry, Webhooks, Signaturschlüssel der eigenen Anwendung.
2. Nach Schaden ordnen. Zuerst, was Geld bewegt oder Kundendaten öffnet: Zahlungs- und Börsenschlüssel, Wallet-Schlüssel, Datenbankzugänge, KI-Schlüssel mit offenem Kontingent. Danach Mail, Analyse und Monitoring.
3. Beim Aussteller sperren und neu ausstellen. Neuen Schlüssel mit möglichst wenig Rechten anlegen, eintragen, ausrollen, alten widerrufen. Bei Datenbanken das Passwort des Nutzers ändern und offene Verbindungen beenden. Wallets mit Guthaben auf neue Adressen umziehen.
4. Protokolle lesen. Bei jedem Aussteller prüfen, ob der alte Schlüssel seit dem 21. Oktober von fremden Adressen benutzt wurde. Auffällig sind neue Regionen, ungewohnte Uhrzeiten und sprunghaft steigende Kosten bei KI-Diensten.
5. Datenschutz prüfen. Konnte ein Fremder mit den Zugängen personenbezogene Daten lesen, läuft die Frist von 72 Stunden für eine Meldung an die Aufsichtsbehörde. Die Entscheidung und ihre Begründung gehören schriftlich in die Akte.
6. Aufwand dokumentieren. Stunden, Personen, Tätigkeiten, externe Rechnungen, zusätzliche Cloudkosten. Ohne diese Liste gibt es weder eine Forderung an Railway noch eine Meldung an die eigene Cyberversicherung.
7. Forderung anmelden. Schriftlich bei Railway, sachlich, mit der Bitte um Bestätigung, ob das eigene Konto betroffen war, und mit der Aufforderung, Protokolle und Befunde aufzubewahren. Die Obergrenze in den Bedingungen verbietet nicht, nach einer freiwilligen Lösung zu fragen.

Infrastruktur neu denken: Was ich aus dem Railway-Vorfall mitnehme

Plattformen wie Railway haben das Gründen schneller gemacht. Ein Repository verbinden, ein paar Variablen eintragen, fertig ist die Anwendung im Netz. Ich nutze solche Dienste selbst gern. Diese Bequemlichkeit hat aber einen Preis, den kaum jemand ausrechnet: Alle Schlüssel eines Unternehmens liegen an einem Ort, bei einem Dritten, und der Dritte haftet für fast nichts. Für mich folgen daraus fünf Regeln.

Erstens: Schlüssel kurzlebig machen. Ein Schlüssel, der ein Jahr gilt, ist ein Jahr lang wertvoll. Wo es geht, ersetzen kurzlebige Anmeldungen die festen Passwörter, etwa über OpenID Connect mit Tokens, die nach Minuten verfallen. Was trotzdem fest sein muss, gehört in einen eigenen Tresor für Geheimnisse und nicht als Klartext in die Oberfläche des Hosters.

Zweitens: Rechte klein schneiden. Ein KI-Schlüssel mit Ausgabenlimit, ein Datenbanknutzer, der nur lesen darf, ein Börsenschlüssel ohne Auszahlungsrecht. Wird so ein Schlüssel gestohlen, bleibt der Schaden begrenzt. Wie ich meine eigenen Werkzeuge aufstelle, beschreibe ich in meinem KI-Stack.

Drittens: Den Austausch üben. Wer seine Zugänge nie gewechselt hat, weiß nicht, welche Dienste daran hängen. Ein Probelauf im ruhigen Moment zeigt, was bricht. Im Ernstfall wird dann nach Liste gearbeitet, nicht nach Gedächtnis.

Viertens: Einen zweiten Weg bereithalten. Ein Anbieter kann ausfallen, Builds sperren oder seine Bedingungen ändern. Wer seine Anwendung als Container baut und die Konfiguration im eigenen Repository hält, zieht in Tagen um statt in Wochen. Europäische Anbieter wie Hetzner, IONOS, OVHcloud, Scaleway oder Clever Cloud stehen dafür bereit. Für Daten, die das Haus nicht verlassen sollen, lohnt auch der Blick auf lokale KI im Mittelstand.

Fünftens: Verträge lesen wie Technik. Haftungsgrenze, Rechtswahl, Gerichtsstand und Meldefristen gehören in jede Anbieterauswahl, genauso wie Preis und Rechenleistung. Passt die Haftung nicht zum Risiko, schließt eine Cyberversicherung die Lücke oder ein anderer Anbieter bekommt den Zuschlag.

Railway und die Politik: Warum der Gesetzgeber handeln muss

Plattformen wie Railway sind längst Infrastruktur. Auf ihnen laufen Shops, Buchungssysteme, Gesundheits-Apps, Fintechs und die Werkzeuge Tausender kleiner Firmen in Deutschland. Fällt so ein Anbieter, fallen viele gleichzeitig. Trotzdem behandelt das Recht ihn wie einen beliebigen Softwareverkäufer, der seine Haftung frei gestalten darf. Laut dem Cloud Report 2026 des Bitkom halten 85 Prozent der befragten Unternehmen Deutschland für zu abhängig von Cloudanbietern aus den USA, ein Jahr zuvor waren es 78 Prozent (Bitkom-Presseinformation). Bei der Haftung ist diese Abhängigkeit besonders teuer.

Die bestehenden Regeln lassen genau die Lücke offen, in die der Railway-Fall fällt:

Die EU-Kommission hat die Schieflage selbst erkannt. Im November 2025 billigte sie den Entwurf von Musterklauseln für Cloudverträge, nach denen jede Seite bei Vorsatz und grober Fahrlässigkeit unbegrenzt haftet, ausdrücklich auch beim Bruch der Vertraulichkeit von Kundendaten (Entwurf der Kommissionsempfehlung). Diese Klauseln sind unverbindlich. Und in Deutschland will die Koalition laut ihrem Koalitionsvertrag das AGB-Recht zwischen Unternehmen lockern, allerdings nur für Verträge zwischen großen Kapitalgesellschaften. Für den kleinen Kunden eines internationalen Hosters ändert das nichts.

Aus meiner Sicht braucht es fünf Schritte:

1. Faire Haftung in Cloudverträgen verbindlich machen. Im laufenden Digital-Omnibus klarstellen, dass Artikel 13 des Data Act auch für die Sicherheitspflichten von Cloud- und Plattformanbietern gilt, unabhängig vom gewählten Recht, sobald der Kunde in der EU sitzt. Die Musterklausel zur unbegrenzten Haftung bei grober Fahrlässigkeit gehört in das Gesetz, nicht in eine Empfehlung.
2. NIS2 bei Anbietern außerhalb der EU durchsetzen. Ein öffentliches Verzeichnis, welcher Cloudanbieter welchen Vertreter in der EU benannt hat. Fehlt er, kann sich das BSI nach § 60 des BSI-Gesetzes selbst für zuständig erklären. Im Fall Railway sollte es das prüfen.
3. Kunden schnell und konkret informieren. Eine Höchstfrist, etwa 24 Stunden, und Pflichtangaben für Meldungen an Kunden: betroffene Projekte, Zeitraum, Merkmale des Angriffs. „Ohne unangemessene Verzögerung“ reicht nicht, wenn das Geld schon vor der Mail abfließt.
4. Kleine Firmen in die Softwarehaftung einbeziehen. Die neue Produkthaftung schützt Verbraucher. Ein Mindestschutz für Kleinst- und Kleinunternehmen bei Sicherheitsmängeln von Cloud- und Softwarediensten gehört in die Bewertung der Richtlinie.
5. Geprüfte Sicherheit und Wechselpläne bei öffentlichem Geld verlangen. Wer mit Fördermitteln digitalisiert oder für den Staat arbeitet, sollte Anbieter mit einem Prüfnachweis wie dem BSI-Katalog C5 wählen und einen getesteten Plan für den Anbieterwechsel haben.

Wen Ihr wegen Railway anschreiben könnt

Politik reagiert auf Fälle, nicht auf Theorien. Wenn Ihr betroffen seid, schreibt es den Stellen, die etwas ändern können. Eine kurze, sachliche Nachricht mit Eurem Aufwand in Stunden und Euro wirkt mehr als jede Pressemitteilung.

Railway ist nicht der erste Anbieter mit einem solchen Vorfall, und er wird nicht der letzte sein. Ich wünsche mir, dass wir daraus mehr machen als eine Woche Aufräumarbeit. Mehr zu meiner Sicht auf Politik und Gesellschaft und auf das Verhältnis von Unternehmern und Politik findet Ihr in meinen anderen Beiträgen. Wart Ihr auch betroffen, und wie hoch war Euer Aufwand? Schreibt mir über das Kontaktformular, ich antworte auf jede Nachricht.

Häufige Fragen

Was ist beim Railway-Sicherheitsvorfall passiert?

Railway meldete am 21. Oktober 2026, dass ein unbefugter Dritter womöglich auf die verschlüsselten Umgebungsvariablen der Kunden zugegriffen und bei einem Teil die entschlüsselten Inhalte erlangt hat. Darin liegen typischerweise API-Schlüssel und Datenbankzugänge. Railway rät allen Kunden, sämtliche Variablen auszutauschen, und pausierte die Builds für viele Stunden.

Bin ich als Railway-Kunde betroffen?

Railway spricht von einer Teilmenge der Kunden und informiert betroffene Konten per Mail, rät aber allen zum Austausch. Ob die eigenen Schlüssel missbraucht wurden, zeigen die Protokolle der Aussteller, etwa ungewohnte Zugriffe bei Datenbank, Zahlungsanbieter oder KI-Dienst seit dem 21. Oktober.

Zahlt Railway Schadensersatz für den Sicherheitsvorfall?

Eine Entschädigung hat Railway nicht angekündigt. Die Nutzungsbedingungen begrenzen die Haftung auf 100 Dollar oder die Entgelte der letzten zwölf Monate und schließen Betriebsunterbrechung, Datenverlust und entgangenen Gewinn aus. Kunden können ihren Aufwand trotzdem schriftlich anmelden und um eine freiwillige Lösung bitten.

Gilt die Haftungsgrenze von Railway auch für deutsche Firmen?

Nach deutschem AGB-Recht wäre sie sehr wahrscheinlich unwirksam. Railway hat aber das Recht von Delaware gewählt, und das ist zwischen Unternehmen zulässig. Streitigkeiten gehen in ein Schiedsverfahren in San Francisco. Gegenüber betroffenen Personen nach der DSGVO wirkt die Grenze dagegen nicht.

Was ist PHP2Shell?

PHP2Shell sind zwei kritische Lücken in PHP, CVE-2026-109618 und CVE-2026-109619, mit 9,2 von 10 Punkten. Sie erlauben es, ohne Anmeldung Code auf Webservern auszuführen. Behoben sind sie seit dem 21. Oktober 2026 in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das BSI rät, ungepatchte Systeme notfalls vom Netz zu nehmen.

Was sind gute Alternativen zu Railway?

Wer umziehen will, findet bei europäischen Anbietern wie Hetzner, IONOS, OVHcloud, Scaleway oder Clever Cloud Server und Plattformdienste mit Rechenzentren in der EU. Wichtiger als der Anbieter ist der Aufbau: Anwendung als Container, Konfiguration im eigenen Repository, Geheimnisse in einem eigenen Tresor und ein geübter Plan für den Wechsel.

Herzlich,
Euer Dennis Weidner

Hinweis: Beim Schreiben dieses Beitrags haben mich KI-Werkzeuge unterstützt, einzelne Bilder sind mit KI bearbeitet. Für Inhalt und Aussagen stehe ich mit meinem Namen.