Hoster gehackt: Umgebungsvariablen in der richtigen Reihenfolge rotieren

Am 21. Oktober 2026 hat Railway eine Sicherheitsmeldung veröffentlicht: Am Morgen desselben Tages bemerkte das Unternehmen ungewöhnliche Aktivität in den Systemen, die die Umgebungsvariablen seiner Kunden speichern. Nach bisherigem Stand der Untersuchung hat ein unbefugter Dritter möglicherweise auf verschlüsselte Variablen zugegriffen und bei einem Teil davon den entschlüsselten Inhalt erhalten. Railway empfiehlt allen Nutzern, jede dort gespeicherte Umgebungsvariable zu rotieren, einschließlich API-Keys und Zugangsdaten für private Registries, und die Logs der betroffenen Dienste zu prüfen. Wer eine Laravel- oder Node-App irgendwo deployt, kann daraus mehr mitnehmen als eine Firmenmeldung: Die eigenen Secrets liegen in der Datenbank von jemand anderem, und an dem Tag, an dem diese Datenbank leakt, zeigt sich, ob man sie austauschen kann.

Was Railway mitgeteilt hat

Laut Railway können die betroffenen Variablen API-Keys sowie Zugangsdaten für Datenbanken und Registries enthalten. Die erste Analyse deute darauf hin, dass nur ein Teil der Nutzer betroffen sein könnte, trotzdem sollen alle rotieren. Railway geht davon aus, dass der Vorfall zu einer Reihe von Angriffen gehört, die sich zuletzt gegen Plattformanbieter richteten, um an Anbieter von KI-Inferenz heranzukommen, und hat diese Anbieter informiert, damit sie Keys vorsorglich widerrufen können. Während der Untersuchung waren Deployments pausiert, neue Versionen ließen sich also erst ausliefern, als die Builds wieder liefen. Railway will bestätigt betroffene Kunden per E-Mail benachrichtigen und Updates auf status.railway.com veröffentlichen.

Das letzte Detail ist für die Planung wichtig. Hängt die Rotation an einem Deployment über genau die Plattform, die kompromittiert wurde, muss man womöglich warten. Ein guter Grund, die Liste fertig zu haben, bevor man sie braucht.

Das Inventar, das du schon haben solltest

Das Folgende ist eine allgemeine Empfehlung, nichts, was Railway vorgegeben hat. Fang mit einer Liste aller Secrets an, die die App nutzt, und woher jedes stammt. Bei einer typischen Laravel- oder Node-App sind das das Datenbankpasswort, Zugangsdaten für Queue und Cache, Keys für den Mail-Dienst, den Zahlungsanbieter und KI-Anbieter, OAuth-Client-Secrets, Signatur-Secrets für Webhooks, Keys für Object Storage wie S3 und Monitoring-Tokens wie bei Sentry. Neben jedes Secret gehören der Anbieter, wer es rotieren darf und welche Dienste es lesen. Ohne diese Liste beginnt jede Rotation damit, alten Code zu lesen, um herauszufinden, womit die App überhaupt spricht.

Laravel hat ein Secret mit Nebenwirkungen. Wer APP_KEY ändert, macht alles ungültig, was damit verschlüsselt oder signiert wurde: verschlüsselte Cookies, Sessions, über Crypt gespeicherte Werte, signierte URLs. Laravel unterstützt eine Liste früherer Keys, die während einer Rotation weiter zum Entschlüsseln dienen; lies die Doku zu deiner Version, bevor du dich darauf verlässt. Die Form ist eine kommagetrennte Liste in der env:

APP_KEY=base64:the-new-key
APP_PREVIOUS_KEYS=base64:the-old-key

Bedenke: Wenn der alte Key geleakt ist, kann jeder, der ihn hat, die damit verschlüsselten Daten lesen. Verschlüssle Wichtiges neu und entferne den alten Key, sobald er nicht mehr gebraucht wird.

Rotieren in dieser Reihenfolge: anlegen, deployen, widerrufen

Die Reihenfolge ohne Ausfall ist einfach. Leg beim Anbieter neue Zugangsdaten an, solange die alten noch funktionieren. Trag den neuen Wert in die env ein und deploye. Prüfe, dass die App ihn wirklich verwendet. Erst dann widerrufst du den alten, und zwar beim Anbieter, nicht nur durch Löschen aus der env-Datei: Ein Key, den du aus deiner App entfernt hast, funktioniert für jeden, der ihn kopiert hat, weiterhin. Danach schau in das Nutzungs-Dashboard jedes Anbieters und such nach Aktivität, die nicht von dir stammt, vor allem bei kostenpflichtigen APIs.

Den nächsten Vorfall kleiner machen

Auch das ist allgemeine Empfehlung: Nutze Keys mit eingeschränktem Geltungsbereich und Ausgabelimit, wo der Anbieter das anbietet, getrennte Keys pro Umgebung, damit ein Leak in Staging kein Leak in Produktion ist, und lass nie ein Secret in ein Git-Repo oder ein Build-Log gelangen. Jede dieser Maßnahmen verkleinert, was dich ein einziger geleakter Speicher kosten kann.

Der nächste Schritt ist konkret. Schreib heute das Inventar für eine App: jedes Secret, sein Anbieter und die Schritte Anlegen, Deployen, Widerrufen dafür. Wenn du auf Railway bist, folge den Anweisungen dort und rotiere jetzt alles. Wenn nicht, mach die Übung trotzdem. Die Frage ist nicht, ob dein Hoster der nächste ist, sondern ob du innerhalb einer Stunde reagieren könntest.

Quelle: Railway-Blog, „Security Disclosure: Wednesday October 21st“.