Das Railway-Datenleck: So rotierst du die Secrets deiner App ohne Ausfallzeit

Am 21. Oktober gab Railway bekannt, dass sich ein Unbefugter Zugriff auf Systeme verschafft hatte, in denen Umgebungsvariablen von Kunden gespeichert sind, und dass der Angreifer bei einem Teil davon möglicherweise an die entschlüsselten Inhalte gelangt ist. Railway pausierte alle Deployments, informierte vorgelagerte Anbieter, damit diese Keys widerrufen, und forderte alle Nutzer auf, ihre Umgebungsvariablen zu rotieren, einschließlich der Zugangsdaten für private Registries.

Der vorläufige Bericht liefert weitere Details:

TechCrunch berichtet, dass Railway von einer größer angelegten Kampagne gegen Plattformen ausgeht, die darauf abzielt, KI-Inferenzanbieter zu kompromittieren. In derselben Woche gab das KI-Coding-Tool OpenCode bekannt, dass Hacker API-Keys und andere Secrets von mehr als 1 % seiner Kunden erbeutet hatten.

Gestohlene KI-Keys sind bares Geld wert. Angreifer verkaufen den Zugang weiter oder verbrennen dein Kontingent für ihre eigenen Workloads, ein Muster, das Forscher LLMjacking nennen. Eine Hosting-Plattform ist ein effizienter Ort, um sie abzugreifen, denn dort liegen bei Tausenden Apps die Keys für OpenAI, Anthropic, Stripe und die Datenbank an einem Ort.

In Railways Bericht steckt ein unbequemes Detail. Die Variablen waren verschlüsselt, aber die Plattform muss sie entschlüsseln können, um sie in deine Builds und laufenden Dienste einzuspeisen. Sobald der Angreifer den richtigen internen Zugriff hatte, hielt ihn die Verschlüsselung im Ruhezustand nicht mehr auf. Das ist kein reines Railway-Problem. Jeder Host, der deinen Code ausführt, kann deine Secrets lesen.

Die Frage lautet also nicht „Ist mein Host sicher?“, sondern „Wenn die Secrets meines Hosts morgen geleakt würden, wie schlimm wäre das, und wie schnell wäre ich wieder auf den Beinen?“

Nimm dir 20 Minuten dafür, auch wenn du bei ein paar Dingen schon auf „Rotieren“ geklickt hast.

1. Erfasse jedes Secret. Liste die Variablennamen in jedem Projekt und jeder Umgebung auf, auch in Staging- und Preview-Umgebungen. Wenn du eine .env.example pflegst, ist sie ein guter Ausgangspunkt:

Notiere zu jedem, was es freischaltet: eine Datenbank, einen Zahlungsanbieter, einen KI-Anbieter, E-Mail, einen Storage-Bucket, ein GitHub-Token.

2. Prüfe Nutzung und Abrechnung bei deinen KI-Anbietern. Achte seit dem 20. Oktober auf Nutzungsspitzen, unbekannte Modelle oder Requests zu ungewöhnlichen Uhrzeiten. Hier zeigt sich Missbrauch am wahrscheinlichsten zuerst.

3. Prüfe die Audit-Logs, die dir zur Verfügung stehen. Railway empfiehlt ausdrücklich, die GitHub-Audit-Logs und die Zugriffe installierter Apps zu überprüfen, ebenso Registry-Logs wie die von Docker Hub. Sieh dir auch die API-Logs deines Zahlungsanbieters und die Verbindungslogs deiner Datenbank an.

4. Prüfe, ob deine Datenbank aus dem Internet erreichbar ist. Railways Bericht empfiehlt, den öffentlichen Netzwerkzugang zu Datenbanken zu entfernen. Zeigt ein geleakter Connection-String auf eine Datenbank, mit der sich jeder verbinden kann, ist das Leck sofort ausnutzbar:

5. Prüfe, was dein Frontend ohnehin schon preisgibt. Vorfälle wie dieser erinnern daran, echte Secrets von Werten zu trennen, die von vornherein öffentlich sind. Ein Key, der in deinem JavaScript-Bundle ausgeliefert wird, war nie geheim.

Der typische Fehler unter Druck: Man widerruft zuerst den alten Key und versucht dann hektisch, den neuen zu deployen, während die App Fehler wirft. Geh stattdessen in dieser Reihenfolge vor:

Arbeite deine Liste nach Schadenspotenzial ab: Zahlungs-Keys, Datenbank-Zugangsdaten, Cloud- und Storage-Keys, Keys von KI-Anbietern, GitHub- und Registry-Tokens, danach alles andere. Railways eigene Empfehlungen konzentrieren sich auf Variablen, die vor dem 21. Oktober gesetzt wurden; in späteren Hinweisen rät Railway zusätzlich, GitHub neu zu verbinden und CLI- und CI-Zugangsdaten neu zu erstellen.

Ein paar Secrets brauchen besondere Sorgfalt:

Du kannst nicht verhindern, dass dein Host gehackt wird. Aber du kannst dafür sorgen, dass ein geleaktes Secret weniger wert ist.

Beschränke Keys so eng wie möglich. Nutze eingeschränkte Keys, wo Anbieter sie anbieten. Ein eingeschränkter Stripe-Key, der nur Checkout-Sessions erstellen kann, nützt einem Angreifer weit weniger als ein vollwertiger Secret Key.

Deckel die Kosten. Setz bei jedem KI-Anbieter monatliche Budgets und Nutzungsalarme. So wird aus einer fünfstelligen Überraschung eine E-Mail.

Trenne Umgebungen. Verwende Produktions-Keys nicht in Staging- oder Preview-Deployments. Jede Umgebung sollte eigene Zugangsdaten haben, damit ein Leck in der einen nicht auch die andere preisgibt.

Halte Datenbanken privat. Nutze das private Netzwerk deiner Plattform, und wenn du Supabase verwendest, stell sicher, dass Row Level Security aktiv ist, damit ein geleakter Anon-Key deine Tabellen nicht offenlegt.

Bewahre Secrets nie in erreichbaren Dateien auf. Eine .env-Datei, die in deinem Web-Root landet, leakt auch ganz ohne Datenleck beim Host.

Schreib dein Rotations-Runbook jetzt auf: die Liste aus Schritt 1, die Reihenfolge oben und wo jeder Key verwaltet wird. Beim nächsten Mal dauert die Rotation dann eine Stunde statt eines ganzen Wochenendes.

Geh das für jede App durch, die du deployst:

Railway hat richtig gehandelt, indem es den Vorfall schnell offengelegt und auf Rotation gedrängt hat. Aber so etwas passiert Hosting- und Entwicklerplattformen immer wieder, weil dort die Keys liegen. Gelassen kommen die Builder durch, die wissen, welche Secrets sie haben, und sie an einem Nachmittag austauschen können.

Wenn du schon beim Aufräumen bist, lohnt sich auch ein Blick darauf, was deine App von außen preisgibt. AppSafe scannt deine Live-Site auf häufige Probleme wie API-Keys in JavaScript-Bundles, offengelegte .env- und .git-Dateien und fehlende Security-Header, mit verständlichen Lösungen. Unsere Launch-Checkliste für KI-gebaute Apps deckt die übrigen Grundlagen ab.

Wenn du alles rotiert hast, starte einen kostenlosen AppSafe-Scan, um sicherzugehen, dass sonst nichts leakt.