Railway, eine der populärsten Deployment-Plattformen für kleine Entwicklungsteams und KI-Projekte, hat am 21. Oktober 2026 eingeräumt, dass ein unbefugter Dritter auf die Systeme zugegriffen hat, in denen die Umgebungsvariablen der Kunden liegen – und bei einem Teil davon die entschlüsselten Inhalte erbeutete. Das Unternehmen fordert deshalb alle Nutzer auf, sämtliche Secrets zu rotieren, und pausierte Builds und Deployments für rund 18 Stunden. Für Betreiber bedeutet das weit mehr als neue Passwörter: Sie müssen ihre Cloud-Konten, Modell-Guthaben und Rechnungen auf fremde Aktivität prüfen.
Was Railway bestätigt – und was nicht
Der erste belastbare Zeitstempel steht auf der Statusseite: Um 07:24 UTC am 21. Oktober meldete Railway ein Problem an der eigenen Backend-Infrastruktur. Um 09:28 UTC war klar, dass Dashboard, API und CLI nicht erreichbar waren und in allen Regionen keine neuen Builds mehr liefen 5. Dass der Ausfall die Folge eines Sicherheitsvorfalls war, erfuhr die Öffentlichkeit erst am Abend.
Um 21:59 UTC veröffentlichte Railway eine Stellungnahme. Darin heißt es, man habe am Morgen «anomale Aktivitäten» in Systemen festgestellt, «die Kunden-Umgebungsvariablen speichern». Ein unbefugter Dritter habe möglicherweise auf verschlüsselte Umgebungsvariablen zugegriffen und bei einem Teil von ihnen «die entschlüsselten Inhalte» erhalten 1. Diese Variablen enthalten in der Regel genau das, was eine Anwendung für den Zugriff auf andere Dienste braucht: API-Keys, Datenbank-Zugangsdaten, Credentials für private Container-Registries 1.
Wie viele Kunden betroffen sind, nennt Railway nicht. Die eigene Ersteinschätzung fällt vorsichtig aus: Der Schaden könnte auf eine «Teilmenge der Nutzer» begrenzt sein. Trotzdem empfiehlt das Unternehmen allen Kunden, tätig zu werden 1. Zur Ursache, zum Einstiegspunkt und zur Frage, ob eine Erpresserforderung vorliegt, äußerte sich Railway auf Nachfrage nicht; Gründer und CEO Jake Cooper kündigte gegenüber TechCrunch einen Post-Mortem-Bericht an 2.
Wie die Angreifer vorgingen – und was offen bleibt
Railway beschreibt den Vorfall als Teil einer Serie: Man glaube, dies sei «Teil einer Reihe von Angriffen», die derzeit auf Plattformunternehmen zielen, «mit dem Ziel, AI-Inference-Anbieter zu kompromittieren» 1. Man habe diese vorgelagerten Anbieter informiert, damit sie alle Keys vorsorglich sperren 1.
Das ist der eigentliche Kern des Vorfalls. Der Angriff richtete sich offenbar nicht auf Railway allein, sondern auf das, was Railway über seine Kunden indirekt erreichte: Konten bei Modellanbietern, Cloud-Providern und Datenbankdiensten. Wer die Umgebungsvariablen einer Deployment-Plattform lesen kann, hält die Schlüssel zu fremden Konten in der Hand.
Wie die Angreifer in die Secret-Speicher gelangten, ist weiterhin unklar. Railway hat weder den Einstiegspunkt noch den Mechanismus der Entschlüsselung veröffentlicht. Ein unabhängiger Beleg für die Folgen stammt von der Sicherheitsforscherin Taylor Monahan: Sie berichtete, Angreifer hätten Krypto-Wallets geleert, deren Private Keys auf Railway lagen; die erste bekannte Transaktion sei am Abend des 21. Oktober erfolgt, mindestens zwei Stunden vor der offiziellen Stellungnahme 4. Railway hat das bislang nicht bestätigt. Solche Forscherbeobachtungen sind ein Indiz, kein Nachweis eines systematischen Abflusses.
Ein Muster: Inference-Kontingente als Beute
Der Vorfall fügt sich in eine Entwicklung, die Behörden seit Monaten beobachten. Am 8. September 2026 veröffentlichten NSA, CISA und FBI eine gemeinsame Warnung: Chinesische KI-Unternehmen – darunter DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun und Z.AI – betrieben industrielle Knowledge-Distillation gegen US-Modelle und extrahierten dabei Milliarden von Tokens über Millionen von Anfragen 3. Den Anbietern empfehlen die Behörden unter anderem, das Verhältnis von Abonnement zu Nutzung zu überwachen und auffällige Konten zu erkennen 3.
Für gestohlene API-Keys gilt eine simple Ökonomie: Wer einen Key besitzt, kann auf Kosten des Eigentümers Inference laufen lassen. Der Sicherheitsforscher Dick O'Brien vom Symantec Threat Hunter Team sagte gegenüber The Hacker News, es gebe keine Hinweise auf eine Verbindung zwischen den von Symantec beobachteten LLMjacking-Aktivitäten und dem Railway-Vorfall. Aber: «API-Keys für KI-Modelle sind wertvoll, weil jeder, der einen besitzt, Inference auf Kosten des Eigentümers laufen lassen kann» 4. Keys aus Plattform-Umgebungsvariablen funktionierten genauso – ob welche missbraucht wurden, habe Railway nicht gesagt 4.
Wenige Tage zuvor hatte das Open-Source-Coding-Tool OpenCode einen ähnlich gelagerten Vorfall eingeräumt: Angreifer erbeuteten nach Unternehmensangaben mehr als ein Prozent der Kunden-API-Keys und anderer Secrets, eingeordnet als AI-Distillation-Angriff 2. Ein Zusammenhang mit Railway ist nicht belegt.
Wie Railway reagierte
Die Reaktion war drastisch und traf alle Kunden. Railway pausierte Builds und Deployments plattformweit und fuhr sie stufenweise wieder hoch – zuerst Enterprise, dann Pro, Hobby, zuletzt Free und Trial 5. Enterprise-Builds standen ab 03:32 UTC am 22. Oktober wieder bereit, also rund 18 Stunden nach Beginn der Störung; Pro folgte um 06:29 UTC, Hobby erst gegen 21:08 UTC. Free- und Trial-Workspaces warteten zu diesem Zeitpunkt weiterhin 5. Neue Registrierungen setzte das Unternehmen zeitweise aus 5.
Parallel rotierte Railway die eigenen Infrastruktur-Zugangsdaten: Alle Storage-Bucket-Credentials wurden ersetzt, neue Werte erscheinen automatisch im Dashboard 5. Sämtliche Railway-API- und Project-Tokens wurden invalidiert und bleiben auch nach der Wiederherstellung ungültig – Nutzer müssen neue erzeugen 5. Wegen Auswirkungen auf benachbarte Cache-Systeme wurden zudem OAuth-Sitzungen verworfen; betroffene Nutzer mussten sich neu anmelden 5. Die API war ab 17:00 UTC am 22. Oktober vollständig wiederhergestellt 5.
Der entscheidende Punkt: Railway kann die Keys seiner Kunden nicht selbst rotieren. Das Unternehmen kann eigene Tokens sperren und Anleitungen liefern – die Rotation der fremden Cloud-, Datenbank- und Modell-Keys müssen die Betreiber selbst erledigen, in der Reihenfolge ihres Schadenspotenzials.
Was Betreiber jetzt konkret tun müssen
Cloud-Keys zuerst
Bei AWS empfiehlt Railway, den betroffenen Key zu deaktivieren statt sofort zu löschen. IAM erlaubt zwei Access Keys pro Nutzer, was ein Überlappungsfenster schafft: neuen Key erzeugen, alten deaktivieren, Dienst neu deployen, alten Key erst nach sauberem Lauf löschen 6. CloudTrail speichert Management-API-Aufrufe 90 Tage. Zu suchen ist nach Aufrufen, die die eigene Anwendung nicht macht – RunInstances, CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole, PutBucketPolicy – und zwar in jeder Region, weil die Event History regional getrennt ist 6. Source-IPs außerhalb der Railway-Egress-Ranges sind ein starker Hinweis 6.
Bei Google Cloud laufen Service-Account-Keys standardmäßig nicht ab. Das Deaktivieren eines Keys blockiert neue Authentifizierung, bereits ausgestellte kurzlebige Tokens bleiben aber bis zu einer Stunde gültig. Wer sofort kappen will, muss das gesamte Service Account deaktivieren und mindestens 60 Minuten warten 7. Zu prüfen sind IAM-Rollen, insbesondere «Service Account Token Creator» auf anderen Konten, sowie die Cloud Audit Logs: Admin-Activity-Logs sind immer aktiv, Data-Access-Logs standardmäßig nur für BigQuery 7. In den Billing-Berichten sind Compute, GPU und Vertex AI die typischen Ziele 7.
Modell-Keys und Guthaben
Bei OpenRouter verbraucht ein geleakter Key direkt das Prepaid-Guthaben und kann Anfragen an jedes verfügbare Modell routen. Railway rät, die Activity-Seite nach API-Key zu gruppieren und nach Modell zu unterteilen: Ausgaben unter dem betroffenen Key auf Modellen, die man nie nutzt, sind der Fund 8. Ersatz-Keys sollten mit Ausgabenlimit und Ablaufdatum erzeugt werden 8. Entsprechende Leitfäden veröffentlichte Railway auch für OpenAI, Anthropic und Grok 5.
Datenbanken, Registries und Beweissicherung
Für PostgreSQL, MySQL, MongoDB und Redis liegen separate Anleitungen vor 5. Entscheidend ist die Reihenfolge: erst Logs exportieren, dann rotieren, dann aufräumen. Wer vom Angreifer erstellte Ressourcen löscht, bevor er sie dokumentiert hat, verliert die Grundlage für Forensik, Versicherung und mögliche Regressansprüche. Railway empfiehlt ausdrücklich, vor dem Löschen Kopien für forensische Zwecke zu ziehen 6.
Ausblick
Der strukturelle Befund ist unbequem für die gesamte PaaS-Branche: Plattformen wie Railway speichern Secrets zentral, weil Deployments sie zur Laufzeit entschlüsselt benötigen. Damit ist der Secret-Store ein Single Point of Failure – nicht für ein Unternehmen, sondern für eine Vielzahl von Konten bei dritten Anbietern. Railway wirbt selbst damit, dass Millionen Entwickler die Plattform nutzen; entsprechend groß ist die Zahl der potenziell betroffenen Fremdkonten.
Ob der Vorfall regulatorische Folgen hat, ist offen. Railway hat angekündigt, nach Abschluss der Untersuchung einen vollständigen Incident Report zu veröffentlichen 5. Bis dahin bleiben drei Fragen unbeantwortet: wie die Angreifer in den Secret-Store kamen, wie viele Kunden tatsächlich betroffen sind – und ob die erbeuteten Keys bereits genutzt wurden. Für Betreiber ist die letzte Frage die einzige, die sie selbst beantworten können. Die Antwort steht in den Logs ihrer eigenen Cloud-Konten.
