Wenn die Plattform ausfällt: Lehren aus Railway und Zeabur

Zwei Berichte in einer Woche

Stand: 24. Oktober 2026. Beide Unternehmen nennen ihre Berichte vorläufig. Die Zahlen und Zeitangaben in diesem Beitrag stammen aus diesen Berichten und können sich mit der endgültigen Untersuchung noch ändern.

Railway, eine Plattform für den Betrieb von Anwendungen und Datenbanken, hat nach eigenem Bericht am 20. Oktober 2026 einen Versuch erkannt, in der Build-Infrastruktur Rechte auszuweiten, und die Build-Pipelines angehalten. Am frühen Morgen des 21. Oktober gelangte der Angreifer laut Bericht an Zugangsdaten der CI-Umgebung, entschlüsselte damit Artefakte mit weiteren API-Zugängen und fragte verschlüsselte Umgebungsvariablen von Kunden ab. Einen Teil davon konnte er entschlüsseln. Railway grenzt den möglichen Kreis auf höchstens 1,85 Prozent aller Workspaces ein, kann aber nicht sagen, welche Variablen im Einzelnen betroffen sind. Darum hat das Unternehmen die Anbieter über alle gespeicherten Schlüssel informiert und bittet jeden Kunden mit einem Konto von vor dem 21. Oktober, seine auf Railway gespeicherten Schlüssel zu rotieren. Laufende Dienste blieben online. Builds und Deployments waren pausiert, bis Railway am 22. Oktober bestätigte, dass der Angreifer keinen internen Zugang mehr hat. Commits aus der Pause wurden nicht ausgerollt und müssen neu deployt werden. Nutzerkonten wurden laut Bericht nicht angetastet; ob Quellcode gelesen wurde, ist noch offen. Als Ziel des Angreifers nennt Railway API-Schlüssel von KI-Anbietern.

Zeabur, eine Plattform für Anwendungen auf gemeinsam genutzten Clustern und dedizierten Servern, berichtet, dass ein Angreifer ab dem 14. Oktober 2026 um 01:36 UTC einen AWS-Schlüssel des Unternehmens und ab 01:40 UTC ein Admin-Token des gemeinsamen Clusters benutzte. Das Token stammte vom 10. Januar 2024, hatte kein Ablaufdatum, stand seit dem 20. Januar 2026 im Klartext in einem Konfigurations-Repository und war von der Rotation nach dem ersten Vorfall im August nicht erfasst. Ein Root-Passwort für dedizierte Server bei Google Cloud lag ebenfalls im Klartext in den Initialisierungseinstellungen. Wie der Angreifer an diese Zugangsdaten kam, kann Zeabur nicht bestätigen. Gelesen wurden laut Bericht die Daten von 321.810 Konten, darunter E-Mail-Adresse, Benutzername und Telefonnummer, 3.218.965 Umgebungsvariablen mit Namen und Werten, 11.536 Plattform-Zugriffstoken als Hashes und 566 API-Schlüssel des Dienstes zSend im Klartext. Alle Token und Schlüssel sind widerrufen. Auf 101 dedizierten Servern meldete sich der Angreifer als Root an, auf 50 davon hinterlegte er eigene SSH-Schlüssel, und er hängte 16 Kopien von Kundenfestplatten an eigene virtuelle Maschinen.

Am 17. Oktober kündigte Zeaburs Gründer an, die Plattform einzustellen. Neukäufe von dedizierten Servern und Domains sind gestoppt. Am 1. Dezember enden die Verlängerungen dedizierter Server, und die Dienste auf den gemeinsamen Clustern werden pausiert. Am 31. Dezember wird alles abgeschaltet; Zeabur schreibt ausdrücklich, dass nicht jeder Dienst bis zu diesem Tag läuft. Löschtermin, Exportfrist und das Ende des Supports standen am 24. Oktober noch nicht fest.

Was die Berichte gemeinsam haben

Die beiden Vorfälle unterscheiden sich in Größe und Ausgang. Die Mechanik dahinter ist dieselbe, und sie ist nicht auf diese beiden Anbieter beschränkt.

Langlebige Zugangsdaten. Zeaburs Admin-Token war fast drei Jahre alt und hatte kein Ablaufdatum. Ein Token, das nie abläuft, bleibt so lange gültig, wie niemand an ihn denkt. Bei Railway führten Zugangsdaten der CI-Umgebung zu Artefakten, aus denen sich weitere API-Zugänge ergaben. In beiden Fällen reichte ein einzelner Fund, um Stufe für Stufe weiterzukommen.

Secrets in einer Form, die die Plattform entschlüsseln kann. Beide Plattformen speichern Umgebungsvariablen verschlüsselt. Das schützt vor dem Verlust einer Datenbankkopie, aber nicht vor einem Angreifer, der die Rolle der Plattform einnimmt. Wer die Schlüssel oder die Berechtigungen hält, mit denen die Plattform selbst entschlüsselt, liest mit. Railway konnte deshalb nur noch eingrenzen, nicht ausschließen, und hat alle Schlüssel als betroffen behandelt.

Build- und CI-Systeme als Einstieg. Bei Railway begann der Vorfall in der Build-Infrastruktur, bei Zeabur lag das Token in einem Konfigurations-Repository. Build-Systeme brauchen breite Rechte, weil sie fremden Code ausführen und Artefakte in viele Umgebungen bringen. Genau deshalb sind sie der Ort, an dem ein Angreifer am meisten gewinnt.

Eine Rotation, die eine Klasse von Zugangsdaten übersieht. Zeabur hat nach dem Vorfall im August rotiert, aber die Admin-Token des Clusters waren nicht auf der Liste. Eine Rotation ist nur so vollständig wie das Inventar, nach dem sie läuft.

Logs, die Lesezugriffe nicht festhalten. Zeabur schreibt, dass die Protokolle des Cloud-Projekts nur Schreibvorgänge abdecken und die Ausgaben der Befehle in den Datenbankcontainern nicht aufgezeichnet wurden. Railway kann nicht sagen, welche Variablen entschlüsselt wurden. Wo das Protokoll fehlt, bleibt nur die Annahme, dass alles gelesen wurde, und die Konsequenz daraus: alles ersetzen.

Gemeinsam ist beiden Berichten auch, was sie gut machen: eine Zeitachse in UTC, Zahlen statt Adjektive, eine klare Trennung zwischen bestätigt, vermutet und offen, und Handlungsanweisungen nach Kundengruppe. Darauf kommen wir in den Fragen am Ende zurück.

Was das für Agenturprojekte heißt

Eine Agentur betreibt selten ein Projekt, sondern viele, für viele Kunden, auf mehreren Plattformen. Eine Mail wie die von Railway, die binnen Stunden eine Rotation verlangt, ist dann keine Aufgabe, sondern Dutzende. Sechs Punkte machen sie beherrschbar.

1. Secrets-Inventar pro Projekt und Kunde. Welche Secrets gibt es, wo liegt jedes davon (Plattform, CI, lokale Dateien, Passwortmanager), und wer kann es entschlüsseln: die Plattform, das CI-System, einzelne Personen. Ohne diese Liste lässt sich eine Rotationsaufforderung nicht beantworten, sondern nur erraten.
2. Ein Rotations-Runbook mit fester Reihenfolge. Erst beim Anbieter einen neuen Schlüssel ausstellen, dann die Plattform aktualisieren und neu deployen, dann den alten Schlüssel widerrufen und prüfen, dass er wirklich nicht mehr gilt. Beide Berichte verlangen genau diese Reihenfolge; wer sie umkehrt, hat einen Dienst ohne gültigen Schlüssel oder einen alten Schlüssel, der weiterlebt.
3. Kurzlebige, eng begrenzte Zugangsdaten. Token mit Ablaufdatum, nur mit den Rechten, die der Dienst braucht, getrennt nach Umgebung. Wo ein Anbieter statt statischer Schlüssel eine Identität für den Workload anbietet, ist sie die bessere Wahl. Ein Admin-Token von 2024 ohne Ablauf darf es in keinem Projekt geben.
4. Ein Exportpfad für jedes Teil. Code liegt in einem Git-Repository außerhalb der Plattform. Daten werden regelmäßig gesichert, und die Wiederherstellung ist geprobt, wie im Beitrag zur Wiederherstellung eines CRM. Domains sind auf den Kunden registriert, mit Zugang zum Registrar und bekanntem Auth-Code; Zeabur bittet seine Kunden heute, Domains selbst zu übertragen. Zertifikate brauchen keinen Export, weil ACME sie überall neu ausstellt. Die DNS-Zone liegt als Datei oder Liste vor, wie das Glossar zum Zonentransfer beschreibt.
5. Vertrag und Informationspflichten. Wer den Kunden wann worüber informiert, steht vor dem Vorfall fest, nicht währenddessen. Eine Agentur, die als Auftragsverarbeiter tätig ist, meldet eine Verletzung dem Verantwortlichen unverzüglich (Art. 33 Abs. 2 DSGVO); der Kunde entscheidet dann über die Meldung an die Aufsicht. Die Checkliste zur Übergabe von Software hält fest, wer welche Zugänge besitzt.
6. Eine Exit-Probe im Jahr. Einmal im Jahr ein Kundenprojekt aus den Exporten an anderer Stelle aufbauen, die Zeit messen, die Lücken schließen. Zeabur hat seinen Kunden gut sechs Wochen bis zum 1. Dezember gelassen. Wer die Probe hinter sich hat, weiß, ob das reicht.

Was das für Kunden von obhut heißt

obhut liefert heute statische Websites und Vorschauen aus. Umgebungsvariablen laufender Kundenanwendungen gibt es bei obhut darum nicht; die Klasse von Daten, um die es bei Railway und Zeabur ging, liegt nicht bei uns. Private TLS-Schlüssel entstehen im Zertifikatsdienst von obhut und werden dort sofort versiegelt; entsiegelt werden sie nur auf dem Edge-Knoten, der die Verbindung annimmt. Wie das funktioniert und wogegen es nicht schützt, steht im Beitrag zu den versiegelten Schlüsseln. In der Datenbank trägt jede Tabelle mit Kundendaten eine erzwungene Zeilensicherheit, und die Rolle, mit der die Anwendung arbeitet, besitzt keine Tabelle. Betrieben wird obhut in Deutschland.

Der Exportpfad braucht bei obhut kein eigenes Werkzeug. Ein statisches Deployment besteht aus Dateien, die die Agentur ohnehin hat. DNS-Einträge sind gewöhnliche Einträge, die jeder Anbieter übernimmt. Zertifikate kommen von Let's Encrypt und lassen sich an jeder anderen Stelle neu bestellen. Nichts davon hängt an einem Werkzeug von obhut.

Immun ist keine Plattform, obhut eingeschlossen. Entscheidend ist, was eine Plattform bei sich hält, wie sie es schützt und wie offen sie berichtet, wenn etwas schiefgeht. Ein Vorfallbericht wie der von Railway oder Zeabur ist darum das Erste, was Sie von einer Plattform lesen sollten, bevor Sie ihr Kundenprojekte anvertrauen: ob es einen gibt und wie er geschrieben ist.

Häufige Fragen

Muss ich rotieren, wenn Railway mir keine Mail geschickt hat?

Ja, wenn das Konto vor dem 21. Oktober 2026 angelegt wurde. Railway kann nicht sagen, welche Variablen entschlüsselt wurden, und bittet deshalb alle diese Kunden um die Rotation. Eine Widerrufsmail eines Anbieters bedeutet nach Railways Bericht nicht zwingend, dass der Schlüssel betroffen war; umgekehrt heißt keine Mail nicht, dass er sicher ist.

Was heißt Envelope Encryption, und warum hat sie nicht gereicht?

Jedes Secret wird mit einem eigenen Datenschlüssel verschlüsselt, und dieser Datenschlüssel wiederum mit einem Hauptschlüssel, der in einem Schlüsseldienst liegt. Das schützt gegen eine gestohlene Datenbankkopie: Ohne den Hauptschlüssel ist sie wertlos. Es schützt nicht gegen einen Angreifer, der die Berechtigungen hält, mit denen die Plattform selbst entschlüsselt. Railway berichtet, dass der Angreifer über Zugangsdaten der CI-Umgebung an weitere API-Zugänge kam und so einen Teil der Variablen entschlüsseln konnte.

Was tue ich mit einem Projekt auf Zeabur bis zum 1. Dezember?

Zuerst alle Secrets der Umgebungsvariablen als offengelegt behandeln: beim Anbieter widerrufen, neu ausstellen, neu deployen. Dann die Daten sichern, vor dem Ablaufdatum des jeweiligen Servers, und die Sicherung an anderer Stelle wiederherstellen. Domains selbst aus dem Dashboard übertragen. Einen dedizierten Server bei Google Cloud rät Zeabur als kompromittiert zu behandeln und neu aufzusetzen. Zeabur stellt eine Migrationsanleitung bereit und rät, nicht auf eine Löschfrist zu warten, denn die stand am 24. Oktober noch nicht fest.

Woran erkenne ich einen guten Vorfallbericht?

An einer Zeitachse mit Datum und Uhrzeit, an Zahlen für das, was gelesen wurde, an einer ehrlichen Liste dessen, was sich nicht bestätigen lässt, an Handlungsanweisungen je Kundengruppe und an einem Abschnitt zu den offenen Fragen. Beide Berichte erfüllen das. Deshalb sind sie trotz der schlechten Nachricht brauchbar, für die eigenen Kunden und für die eigene Liste.