Railway: Angreifer lasen entschlüsselte Umgebungsvariablen von Kunden aus

Michael Dobler

Autor Dr. Web

22. Okt. 2026

3 Min. Lesezeit

Bei der Hosting-Plattform Railway griffen Unbekannte nach bisherigem Stand auf verschlüsselt gespeicherte Umgebungsvariablen von Kunden zu und erbeuteten einen Teil davon im Klartext. In solchen Variablen liegen meist API-Schlüssel für Sprachmodelle und Passwörter für Datenbanken. Ausgetauschte Schlüssel greifen erst nach dem nächsten Deployment, doch Railway hatte alle Builds gestoppt und gibt sie nur Tarif für Tarif wieder frei.

Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügen

Spät am 21. Oktober schaltete Nevo David, Gründer des Social-Media-Planers Postiz, seinen Dienst für alle Kunden ab. Anthropic und Stripe hätten ihm geschrieben, seine Schlüssel seien kompromittiert. Von Railway komme dagegen keine Auskunft, schrieb David auf X.^[5] Railway rät allen Kunden, sämtliche Variablen auszutauschen, obwohl der Vorfall nach erster Analyse nur einen Teil der Konten betrifft.^[1]

Auf einen Blick

Das Wichtigste in Kürze

Angreifer erreichten die Systeme, in denen Railway die Umgebungsvariablen der Kunden speichert.
Railway setzte die Zugangsdaten aller Speicherbereiche (Buckets), die GitHub-Verbindungen und alle eigenen API-Token zurück.
Builds laufen wieder für Enterprise- und Pro-Kunden, Hobby-, Free- und Testkonten warten noch (Stand 22. Oktober, 9:11 Uhr).
Railway sieht den Einbruch als Teil einer Angriffsserie, die über Plattformanbieter auf KI-Anbieter zielt.

Warum half die Verschlüsselung nicht?

Kleiner weißer Safe, geöffnete hellblaue Tür, Schlüssel im Schloss mit Anhänger „Verschlüsselt“ — Verschlüsselte Variablen werden beim Container-Start entschlüsselt. Railway-Systeme wurden kompromittiert, Angreifer konnten Klartexte auslesen

Die Verschlüsselung schützt die Variablen nur im gespeicherten Zustand. Ein Container liest seine Variablen beim Start,^[2] also muss Railway sie für jedes Deployment selbst entschlüsseln und an den Container übergeben. Ein Eindringling im System, das diesen Schritt erledigt, sieht den Klartext. Wie die Angreifer hineinkamen und wer sie sind, hat Railway nicht mitgeteilt.

In der Nacht ersetzte Railway die S3-Zugangsdaten aller Speicher-Buckets und entwertete die GitHub-Token der Kundenkonten. Die alten Werte sind ungültig, laufende Dienste übernehmen die neuen aber erst mit dem nächsten Deployment. Als Zugang zur Ablage ihrer Container-Abbilder hinterlegte GitHub-Token der Kunden hat Railway nur gelöscht: Auf GitHub gelten sie weiter, bis der Kunde sie dort widerruft.^[2]

Warum sind Schlüssel für KI-Dienste so begehrt?

Mit einem gestohlenen OpenRouter-Schlüssel lassen sich alle Modelle des Dienstes abfragen, bezahlt aus dem Guthaben des Kunden.^[4]

Vier Tage vor Railways Warnung hatte OpenCode, Anbieter eines KI-Agenten zum Programmieren, Kunden gewarnt: Über ein Altsystem waren Unbekannte an hinterlegte Schlüssel für OpenAI, Anthropic und Google gelangt. OpenCode brachte den Vorfall nach Berichten von Fachmedien mit einer groß angelegten Destillation in Verbindung, bei der ein Anbieter sein Modell mit den Antworten eines fremden Modells trainiert. Anthropic gibt an, Konten für solche Destillation oft binnen zwei Stunden zu sperren. Gestohlene Kundenschlüssel können diese Sperren unterlaufen, weil die Anfragen dann von bezahlten Konten echter Firmen kommen.

Ebenfalls am 21. Oktober flog eine manipulierte LiteLLM-Version auf, die Zugangsdaten von Entwicklerrechnern abgriff. Wie leicht solche Daten aus .env-Dateien abfließen, zeigte im August GitHub Copilot, das Zeilen daraus mit in die Cloud schickte.

Ein KI-Schlüssel ohne Kostenobergrenze ist ein Blankoscheck. Bei Railway lagen solche Schecks gebündelt in einem System.
Markus Seyfferth, Chefredakteur Dr. Web

Der Railway-Vorfall in Zahlen

Wie lange Kunden warten mussten und was Railway zurückgesetzt hat

14,5 Std.

vergingen zwischen der ersten Störungsmeldung und dem Sicherheitshinweis auf der Statusseite

Arten von Zugängen tauschte Railway selbst aus: Speicher-Buckets und GitHub-Token

Anleitungen für Kunden, von PostgreSQL über Anthropic bis Stripe

Stufen für die Rückkehr der Builds: Enterprise, Pro, Hobby, zuletzt Free und Testkonten

Ablauf (MESZ)

21.10., 9:24 UhrStatusseite

EreignisRailway untersucht eine Störung

Buildskeine Angabe

21.10., 13:33 UhrDashboard, API und Kommandozeilenwerkzeug nicht erreichbar

EreignisRailway hat das Problem eingegrenzt

Buildsin allen Regionen pausiert

21.10., 23:59 UhrSicherheitshinweis

EreignisRat zum Austausch aller Variablen

Buildspausiert

22.10., 0:10 UhrSpeicher-Buckets

Ereignisneue Zugangsdaten für alle Buckets

Buildspausiert

22.10., 6:17 UhrProgrammierschnittstelle

Ereignisalle Railway-API-Token ungültig

Buildsnur Enterprise

22.10., 8:29 UhrPro-Tarif

EreignisBuilds wieder verfügbar

BuildsEnterprise und Pro

Was sollten Railway-Kunden jetzt tun?

Aus Railways 13 Anleitungen haben vier Schritte Vorrang:^[3]

Beim Anbieter sperren: Widerrufen Sie Schlüssel zuerst bei OpenAI, Anthropic, OpenRouter, Stripe oder AWS, erst danach gehört der neue Wert in Railway.
Verbrauch prüfen: Lassen Sie sich die Nutzung in der Konsole des KI-Anbieters nach Schlüsseln getrennt anzeigen. Taucht ein Modell auf, das Sie mit diesem Schlüssel nie nutzen, spricht dieser Fund für Missbrauch.^[4]
Obergrenzen setzen: Legen Sie Ersatzschlüssel gerne mit Kostenobergrenze und Ablaufdatum an.^[4]
GitHub aufräumen: Stellen Sie die GitHub-Verbindung neu her und widerrufen Sie die alten Token direkt auf GitHub.^[2]

Liegen in den Datenbanken personenbezogene Daten, müssen Verantwortliche prüfen, ob sie den Vorfall der Datenschutzaufsicht melden. Die Meldung ist möglichst binnen 72 Stunden nach Bekanntwerden fällig (Art. 33 DSGVO).^[6] Railway muss als Auftragsverarbeiter betroffene Kunden unverzüglich informieren (Art. 33 Abs. 2).