Der Cloud-Hoster Railway hat am 10. November 2026 seinen Abschlussbericht zum Angriff vom 20. und 21. Oktober (UTC) veröffentlicht. Nach Railways Darstellung kettete der Angreifer mehrere Schwachstellen aneinander, bewegte sich seitwärts durch interne Systeme und entschlüsselte am Ende Umgebungsvariablen eines Teils der Kunden. Die missbräuchliche Nutzung gestohlener KI-Zugangsdaten schätzt das Unternehmen auf rund 740.000 US-Dollar.

Wie viele Kunden tatsächlich Geheimnisse verloren haben, lässt sich laut Bericht nicht genau sagen. Railway nennt eine Obergrenze: Bei höchstens 1,85 Prozent der Workspaces, rund 100.000, könnten Variablen entschlüsselt worden sein. Die Protokolle weisen nur Umgebungen aus, nicht einzelne Variablen. Sicher betroffen sind verknüpfte Zugangsdaten von 1.852 Nutzern, nämlich eigene Agenten-Schlüssel (BYOK) und GitHub-OAuth-Tokens. Alle wurden zurückgesetzt, Anmeldungen mit gestohlenen Daten hat Railway nach eigenen Angaben nicht festgestellt.

Vom Build-Job zum Schlüsseldienst: die Angriffskette

Los ging es am 20. Oktober um 7:28 Uhr UTC. Railways Build-Infrastruktur ließ damals mehrere Kunden-Builds isoliert auf derselben virtuellen Maschine laufen. Über eine bis dahin unbekannte Schwachstelle brach der Angreifer teilweise aus der Dateisystem-Isolation aus und las Dateien des Hosts, darunter ein internes Token, mit dem Build-Server etwa fertige Images in die Registry schieben.

Das Token sollte nur Build-Aufgaben erlauben. Der selbst betriebene Temporal-Cluster, der Teile der Builds steuert, akzeptierte es aber als vertrauenswürdigen Client. So las der Angreifer die gespeicherten Verläufe von 353 fremden Builds samt übergebener Variablen. Über zwischengespeicherte Repository-Snapshots holte er sich außerdem eine Kopie von Railways internem Monorepo.

Um 13:58 Uhr UTC alarmierten ungewöhnliche API-Aufrufe den Bereitschaftsingenieur. Railway stoppte die Builds und tauschte das Token. Doch im erbeuteten Code fand der Angreifer einen zweiten Weg: eine fehlerhaft definierte OIDC-Bindung in einer von Railways Cloud-Umgebungen. Über sie bekam er am 21. Oktober um 3:26 Uhr UTC ein kurzlebiges Cloud-Zugangsdatum, wie es sonst das CI/CD-System für Deployments nutzt. Damit holte er ein langlebiges Zugangsdatum für die Datenbank mit den verschlüsselten Umgebungsvariablen und einen SSH-Schlüssel des Deployment-Systems. Mit dem Schlüssel meldete er sich auf einem Orchestrierungsrechner an, auf dem in einer Datei ein weiterer langlebiger Schlüssel für den Schlüsseldienst (KMS) lag.

Symbolbild: Netzwerkkabel an einem Switch in einem Serverschrank

Symbolbild – Foto: ProjectManhattan / Wikimedia Commons, Lizenz CC BY-SA 3.0

Railway verschlüsselt Variablen nach dem Envelope-Prinzip: Jede Umgebung hat einen eigenen Datenschlüssel, der mit einem Hauptschlüssel im KMS eines vorgelagerten Cloud-Anbieters verschlüsselt ist. Der Hauptschlüssel verlässt das KMS nie, doch mit gültigen Zugangsdaten konnte der Angreifer den Dienst schlicht um die Entschlüsselung bitten. Zwischen 4:07 und 5:21 Uhr UTC zog er Datensätze aus der Datenbank, laut Protokollen per regulärem Ausdruck nach Namen von KI-Schlüsseln gefiltert und bevorzugt bei Kunden mit vielen Variablen. Entschlüsselt wurde ab 4:42 Uhr. Um 7:14 Uhr sperrte Railway alle Cloud-Zugangsdaten und den Entschlüsselungsdienst, um 9:24 Uhr war der Angreifer nach Railways Angaben draußen. Seit dem ersten Ausbruch waren knapp 26 Stunden vergangen, gut 19 davon wusste Railway von dem Eindringling.

Was seit dem Vorbericht vom Oktober neu ist

Am 21. Oktober hatte Railway nur ungewöhnliche Aktivität gemeldet und allen Kunden geraten, sämtliche Variablen zu tauschen. Der Vorbericht vom 22. Oktober nannte bereits die Obergrenze von 1,85 Prozent, hielt Details aber zurück. Neu sind die vollständige Kette, die 353 Build-Verläufe, die 1.852 Nutzer und die Schadenssumme. Zudem korrigiert der Bericht den Ablauf: Scheinkonten legte der Angreifer schon ab dem 18. Oktober an, und die Entschlüsselung begann um 4:42 Uhr, nicht erst nach 5:27 Uhr. Einen Zugriff auf Quellcode von Kunden mochte Railway im Oktober nicht ausschließen, jetzt gebe es dafür keine Hinweise.

Geändert hat sich auch die Haltung zu den Kosten. Am 26. Oktober schrieb Railway noch, es könne Ausgaben über kompromittierte Schlüssel nicht erstatten. Jetzt springt das Unternehmen ein, wo Anbieter nicht zahlen. Laut Bericht erstatten AWS (Bedrock) und Google (Gemini) nach ihren Betrugsregeln, OpenAI und SpaceXSI, der Anbieter von Grok, prüfen Einzelfälle, mit Anthropic laufen Gespräche, und OpenRouter lehnt Erstattungen ab. Bei OpenRouter übernimmt Railway die Kosten vollständig, bei Anthropic vorerst. Ab 9:25 Uhr UTC am 21. Oktober hatte Railway GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google und Stripe gebeten, möglicherweise betroffene Schlüssel zu sperren.

KI-Agenten auf Angreiferseite: Railways Darstellung

Über den Einzelfall hinaus interessant ist, was Railway über die Werkzeuge des Angreifers schreibt. Er habe viele Wege parallel ausprobiert, Railway ebenso parallel abgedichtet; die Lage sei zu einem Wettlauf der Agenten-Geschwindigkeit geworden. Unter Berufung auf das Sicherheitsunternehmen Wiz schreibt Railway, der Angreifer habe „abliterierte“ Sprachmodelle eingesetzt, also Modelle ohne Sicherheitssperren, dazu ein Steuerprogramm ähnlich der KI-Pentest-Plattform ARTEX. Mit dem Monorepo habe er viele Agenten gleichzeitig auf Lückensuche schicken können. Dass er den Code kannte, bemerkte Railway erst, als er Endpunkte abklopfte, die seit Wochen, Monaten oder Jahren nicht mehr genutzt wurden.

Unabhängig bestätigt ist dieser Teil bislang nicht. Wiz hat am 30. Oktober unter dem Titel „Black October“ Vorfälle bei mindestens neun KI-Entwicklerplattformen im Oktober zusammengetragen, darunter Railway, Fireworks AI, OpenCode und Warp, und einen Markt für den Weiterverkauf gestohlener KI-Schlüssel beschrieben. Den Railway-Vorfall einem Akteur zuordnen kann diese Recherche nicht, das räumt Railway selbst ein. Die beauftragte Forensikfirma nennt Railway nicht, ihre Untersuchung läuft. Beim Internet Crime Complaint Center (IC3) des FBI hat Railway eine formelle Beschwerde eingereicht.

Als Motiv vermutet Railway Destillation, also das Training eigener Modelle mit den Antworten großer KI-Modelle. Die Schlüssel seien wohl an Dienste gegangen, die Zugang zu KI-Anbietern weiterleiten oder weiterverkaufen. Ob der Angreifer solche Dienste selbst betreibt, ist laut Bericht offen.

Was Railway-Kunden jetzt tun sollten

  • Geheimnisse tauschen: Railway rät allen Kunden, vor dem 21. Oktober gespeicherte Variablen zu ersetzen, vor allem KI-Schlüssel, Datenbank-, Registry-, Cloud- und Zahlungszugänge. Reihenfolge laut Railways Anleitungen: alten Schlüssel beim Anbieter sperren, neuen erzeugen, in Railway eintragen, neu deployen.
  • Abrechnungen prüfen: In den Konsolen der KI-Anbieter die Nutzung je Schlüssel ab dem 20. Oktober ansehen. Auffällig sind Modelle, die du nicht nutzt, ungewohnte Mengen und fremde IP-Adressen. Unberechtigte Kosten meldest du über Railways Formular und beim Anbieter.
  • Schaden begrenzen: Wie schnell gestohlene Schlüssel leergeräumt werden, zeigt Wiz an zwei Fällen aus der Welle, ohne die betroffene Plattform zu nennen: rund 800.000 Aufrufe in 30 Stunden über den einen, rund 1,7 Millionen in 13 Stunden über den anderen Schlüssel, nach Listenpreis zusammen wohl mehr als 100.000 US-Dollar. Ausgabegrenzen pro Schlüssel helfen, wo es sie gibt. Bei OpenRouter etwa lässt sich für jeden Schlüssel ein Kreditlimit setzen, das sich täglich, wöchentlich oder monatlich zurücksetzt.
  • OIDC-Vertrauensstellungen prüfen: Was an Railways OIDC-Bindung falsch war, steht nicht im Bericht. Wer selbst etwa GitHub Actions per OIDC mit AWS verbindet, sollte die Trust Policies kontrollieren. Laut GitHub muss mindestens eine Bedingung definiert sein; die Prüfung des sub-Claims begrenzt, welche Workflows die Rolle übernehmen dürfen.
  • Zugänge nachziehen: Datenbanken nicht öffentlich erreichbar machen, Audit-Logs von GitHub und Registry prüfen, CLI- und CI-Tokens neu erstellen und GitHub neu verbinden – Railway hatte am 21. Oktober alle Sitzungen und Tokens ungültig gemacht.

Für den Tausch auf der Kommandozeile hilft die Railway-CLI. Ein neu gesetzter Wert löst standardmäßig ein neues Deployment aus:

# Nur die Namen der Variablen des verknüpften Service anzeigen
railway variable list --kv | cut -d= -f1

# Neuen Schlüssel per stdin setzen, damit er nicht in der Shell-History landet
read -rs NEUER_KEY && printf '%s' "$NEUER_KEY" | railway variable set OPENAI_API_KEY --stdin

Railway hat nach eigenen Angaben alle ausgenutzten Schwachstellen geschlossen. Jeder Build läuft jetzt in einer eigenen kurzlebigen virtuellen Maschine, deren Token nur noch ein bestimmtes Image in die Registry schieben darf, und nur noch der Secrets-Dienst kommt an die Entschlüsselungsschlüssel.

Quellen

Bildnachweis