Railway: Möglicher Zugriff auf Kunden-Secrets, Rotation empfohlen

Der PaaS-Anbieter Railway hat am 21. Oktober 2026 einen Sicherheitsvorfall offengelegt: Ein unbefugter Dritter hatte möglicherweise Zugriff auf die Systeme, in denen Railway die Umgebungsvariablen seiner Kunden speichert, und konnte einen Teil davon entschlüsselt auslesen. Weil dort typischerweise Datenbank-Passwörter, Cloud-Schlüssel, Registry-Zugänge und API-Tokens liegen, betrifft der Vorfall jedes Team, das Anwendungen oder Datenbanken bei Railway betreibt.

Railway spricht zwar von einer vermutlich begrenzten Teilmenge betroffener Nutzer, empfiehlt aber allen Kunden, sämtliche dort hinterlegten Secrets sofort zu rotieren und die Logs der zugehörigen Dienste zu prüfen. Wer keine Workloads, Variablen oder Tokens bei Railway hat, ist nicht betroffen. Für Railway-Kunden ist das keine Aufgabe für das nächste Wartungsfenster, sondern für heute.

Was ist passiert?

Laut dem Disclosure-Beitrag von Railway erkannte das Unternehmen am Morgen des 21. Oktober ungewöhnliche Aktivität an Systemen mit Kunden-Umgebungsvariablen. Die bisherige Untersuchung deute darauf hin, dass verschlüsselte Variablen abgegriffen und bei einem Teil davon auch die Klartexte gewonnen wurden. Railway ordnet den Angriff selbst als Teil einer Serie von Angriffen auf Plattformanbieter ein, deren Ziel die Kompromittierung von KI-Inferenzanbietern sei. Diese Anbieter wurden informiert, um betroffene Schlüssel vorsorglich zu sperren.

Als Sofortmaßnahme pausierte Railway alle Deployments. Laut Statusseite wurden die Builds am 22. Oktober stufenweise wieder freigegeben, zuerst für Enterprise und Pro, am Abend auch für Hobby, Free und Trial. Neue Registrierungen bleiben vorerst gesperrt, ein vorläufiger Incident-Bericht ist angekündigt. Railway hat außerdem alle Railway-API-Tokens und Projekt-Tokens ungültig gemacht, die S3-Zugangsdaten aller Storage-Buckets neu erzeugt und die bei Railway hinterlegten GitHub-Tokens entfernt. Betroffene Konten will Railway direkt per E-Mail informieren. Opferzahlen nennt das Unternehmen nicht.

Wer ist betroffen?

Betroffen sind alle Railway-Workspaces, in denen Secrets als Umgebungsvariablen liegen, unabhängig vom Tarif. Das umfasst Verbindungsdaten zu PostgreSQL, MySQL, MongoDB und Redis aus den Railway-Templates, Schlüssel für AWS und Google Cloud, Tokens für GitHub, Stripe sowie API-Schlüssel für KI-Dienste wie OpenAI, Anthropic, OpenRouter oder Grok. Auch Zugangsdaten zu privaten Container-Registries zählen dazu. Nicht betroffen sind Anwendungen, die nie bei Railway liefen, und Secrets, die nachweislich nie in Railway hinterlegt waren.

Wie kritisch ist das?

Es handelt sich um einen Datenabfluss bei einem Anbieter, nicht um eine Lücke in eigener Software. Ein Patch hilft deshalb nicht, nur das Austauschen der Zugangsdaten. Kritisch ist der Vorfall, weil gültige Secrets direkten Zugriff auf Datenbanken, Cloud-Konten und kostenpflichtige APIs erlauben. The Hacker News zitiert eine Sicherheitsforscherin, nach deren Angaben auch Kryptowallets geleert wurden, deren private Schlüssel auf Railway lagen. Das ist eine Einzelaussage und von Railway nicht bestätigt. Solange der Umfang unklar ist, sollten Railway-Kunden jedes dort gespeicherte Secret als kompromittiert behandeln.

Was sollten Admins jetzt tun?

• Inventar erstellen: alle Railway-Projekte, Umgebungen und Variablen auflisten und zu jedem Secret notieren, welcher externe Dienst und welche weiteren Systeme es nutzen.
• Datenbank-Passwörter rotieren: Bei den Railway-Templates über die Regenerate-Funktion in der Database View, danach alle abhängigen Dienste neu deployen. Öffentlichen Zugriff über den TCP-Proxy abschalten, wenn er nicht gebraucht wird, und externe Nutzer wie CI oder BI-Werkzeuge manuell nachziehen.
• Cloud-Schlüssel sperren: AWS-Access-Keys und Google-Cloud-Servicekonto-Schlüssel deaktivieren, neu ausstellen und in CloudTrail beziehungsweise den Cloud Audit Logs nach Aktivität suchen, die nicht vom eigenen Team stammt, etwa neue Ressourcen oder unbekannte Kosten.
• API-Schlüssel tauschen: Tokens für OpenAI, Anthropic, OpenRouter, Grok und Stripe neu erzeugen und die Verbrauchs- und Abrechnungsübersichten auf unerwartete Nutzung prüfen.
• GitHub neu verbinden und alte Registry-Tokens direkt bei GitHub widerrufen, da sie laut Railway dort weiter gültig sind. Bucket-Dienste neu deployen und neue Railway-API-Tokens für CLI und Automatisierung erzeugen.
• Im Audit-Log des Workspaces die Änderungen durch Railway-Mitarbeiter von eigenen Änderungen trennen und die Einträge für die eigene Vorfallsdokumentation exportieren.

Einordnung für Unternehmen

Der Vorfall zeigt ein strukturelles Risiko: Umgebungsvariablen bei einem Plattformanbieter sind bequem, bündeln aber viele hochwertige Zugangsdaten an einer Stelle. Unternehmen sollten Secrets mit möglichst engen Rechten und kurzer Laufzeit ausstellen, kurzlebige Tokens oder Identitätsföderation statt dauerhafter Cloud-Schlüssel bevorzugen und Budget-Alarme bei KI- und Cloud-Anbietern setzen. Ein gepflegtes Verzeichnis, welches Secret wo liegt, macht die Rotation im Ernstfall zur Routine statt zur Suche. Ob ein Vorfall nach DSGVO meldepflichtig ist, hängt davon ab, ob über die abgeflossenen Zugangsdaten personenbezogene Daten erreichbar waren. Das sollten Verantwortliche zeitnah prüfen und dokumentieren.

Passende Anleitungen auf S-EDV

• Infisical mit Docker: Secrets zentral verwalten
• Gitleaks: versehentlich eingecheckte Secrets in Repositories finden
• Docker Compose Secrets statt Klartext in Umgebungsvariablen

Quellen

• Railway: Security Disclosure vom 21. Oktober 2026
• Railway-Statusseite zum Vorfall
• Railway: Hinweise zu Buckets und GitHub nach dem Zurücksetzen der Zugangsdaten
• Railway: Prüfung auf ungewöhnliche Google-Cloud-Zugriffe
• BleepingComputer: Railway fordert Rotation von Secrets
• The Hacker News: Angreifer hatte möglicherweise Zugriff auf Kunden-Secrets