Railway und Heroku wurden beide über geteilte Infrastruktur gehackt. Das eigentliche Muster, kein Verkaufsgespräch.

Zwei Plattformen, die Anwendungen vieler anderer Leute betreiben, haben in den letzten Jahren echte, bestätigte Sicherheitsvorfälle veröffentlicht: Railway im Oktober 2026 und Heroku im April 2022. Beide sind von den Unternehmen selbst dokumentiert, nicht Gerücht. Und beide führen auf dieselbe zugrunde liegende Risikoform zurück: eine Schwachstelle in Infrastruktur, die die Plattform im Auftrag vieler Kunden gleichzeitig betreibt, die sich in Zugriff auf Daten von Kunden verwandelte, die mit dem ursprünglichen Fehler nichts zu tun hatten.

Dieser Beitrag ist nicht „jede Plattform wurde gehackt“ – das wäre falsch, und das behaupten wir nicht. Es sind zwei echte, gut dokumentierte Vorfälle, was sie tatsächlich gemeinsam haben, und was ein Bring-your-own-Server-Modell an diesem spezifischen Muster ändert. Wir haben bereits eine vollständige Aufschlüsselung des Railway-Vorfalls allein geschrieben: Railways Umgebungsvariablen-Breach. Dieser Beitrag betrachtet das Muster über beide hinweg.

Was in beiden Fällen tatsächlich passierte

Railway, Oktober 2026. Railways eigener vorläufiger Bericht beschreibt einen Angreifer, der Privilegien innerhalb von Railways Build-Infrastruktur eskalierte, die CI-Umgebung erreichte und von dort Systeme erreichte, die Kunden-Umgebungsvariablen speichern – wobei ein Teil davon entschlüsselt wurde. Nach Railways eigener Zählung waren bis zu 1,85 % aller Workspaces, etwa 100.000, potenziell von offengelegten Umgebungsvariablen betroffen. Die vollständige Zeitleiste und Railways eigene Worte stehen in unserem eigenen Breach-Beitrag.

Heroku, April 2022. Ein Bedrohungsakteur erlangte die Zugangsdaten eines Heroku-Maschinenkontos, die in einem archivierten privaten GitHub-Repository mit Heroku-Quellcode liegen geblieben waren. Dieser Zugriff erreichte eine Heroku-Datenbank, die GitHub-Integrations-OAuth-Tokens von Kunden speicherte, und von dort eine interne Kundendatenbank, aus der gehashte und gesalzene Kundenpasswörter exfiltriert wurden. Heroku legte dies am 15. April 2022 offen, widerrief die Tokens der GitHub-Integration, erzwang einen Passwort-Reset für betroffene Nutzer, und die GitHub-Integration selbst blieb bis zum 25. Mai 2022 offline. GitHubs eigenes Security-Team bestätigte separat, dass die gestohlenen OAuth-Tokens genutzt wurden, um auf private Repositories über Dutzende Organisationen hinweg zuzugreifen, einschließlich npms.

Das Muster darunter, in beiden Fällen

Keiner dieser Fälle war ein Kunde, der etwas falsch gemacht hat, und keiner war ein Brute-Force-Angriff auf ein einzelnes Konto. In beiden Fällen war der Einstiegspunkt ein Stück Infrastruktur, das die Plattform zentral betreibt – Railways Build-/CI-Pipeline, Herokus interne Versionsverwaltung und Maschinenkonto-Zugangsdaten –, und der Austrittspunkt waren Daten einer großen Zahl unbeteiligter Kunden, erreicht durch genau dieses eine geteilte System.

Das ist der eigentliche Mechanismus, den man benennen sollte: Auf einer Multi-Tenant-Plattform liegen das Build-System, die Control Plane und die Compute, die Kundencode ausführt, typischerweise alle innerhalb desselben internen Perimeters des Betreibers. Ein Credential-Leak oder ein Privilege-Escalation-Bug in einem dieser Systeme ist potenziell ein Weg in die Daten aller, weil „alle“ sich die Infrastruktur teilen, in der dieser Bug lebt.

Was ein BYO-Server-Modell tatsächlich ändert – und was nicht

Wir haben das im Railway-Beitrag sorgfältig geschrieben, und es gilt hier genauso: Railyards eigene Control Plane speichert Kunden-Umgebungsvariablen zentral, verschlüsselt im Ruhezustand, auf dieselbe allgemeine Weise wie jede Plattform, die Kunden-Secrets hält – Railway und Heroku eingeschlossen. Eine Kompromittierung von Railyards Control-Plane-Datenbank und ihrem Verschlüsselungsschlüssel ist dieselbe allgemeine Risikoklasse, die jeder zentrale Secrets-Speicher trägt, unabhängig davon, wo die Compute läuft. Einen eigenen Server zu besitzen lässt diese Datenbank nicht verschwinden.

Was sich ändert, ist, was die entschlüsselte, live Kopie eines Secrets berührt, sobald sie diesen Speicher verlässt. Auf Railyard werden Variablen einmal, zum Deploy-Zeitpunkt, entschlüsselt und an einen Server in genau dem eigenen Cloud-Account dieses Kunden ausgeliefert – nicht an eine geteilte Compute-Flotte, die die Plattform selbst betreibt. Es gibt keine einzelne Build-Pipeline oder CI-Umgebung, deren Kompromittierung einem Angreifer einen Fußabdruck in den laufenden Anwendungen anderer Kunden verschafft, weil es keine geteilte Flotte laufender Anwendungen gibt, durch die man sich bewegen könnte. Die laufende Umgebung jedes Kunden ist eine andere Maschine in einem anderen Account.

Das ist eine enge, spezifische Behauptung: Sie schließt einen Weg – ein Bug in geteilter Plattform-Infrastruktur, der zu einem Zugang zu den laufenden Secrets vieler unbeteiligter Kunden gleichzeitig wird – nicht jeden Weg. Es ist keine Behauptung, dass Railyard, oder irgendjemand, immun gegen einen Breach ist. Ein Unternehmen, das dir sagt, es könne nicht gehackt werden, ist ein Unternehmen, dem gegenüber du skeptischer sein solltest, nicht weniger.

Was man auf jeder Plattform tatsächlich dagegen tun kann

• Secrets nach einem Zeitplan rotieren, nicht nur nach einer Offenlegung. Ein statischer, langlebiger API-Key im Dashboard jeder Plattform ist eine dauerhafte Haftung, unabhängig von einem einzelnen Vorfall.
• Zugangsdaten eng abgrenzen. Je kleiner der Blast-Radius eines einzelnen geleakten Keys, desto weniger kostet dich ein Breach jeder Art.
• Frag, was kompromittiert werden muss, um ein entschlüsseltes Secret in aktiver Nutzung zu erreichen – nicht nur, ob Daten „im Ruhezustand verschlüsselt“ sind. Verschlüsselung im Ruhezustand ist überall selbstverständlich; die eigentliche Frage ist, wie viele geteilte Systeme zwischen einem Bug irgendwo anders auf der Plattform und deinen tatsächlich laufenden Secrets liegen.
• Lies die Incident-Reports, die Unternehmen tatsächlich veröffentlichen. Railways und Herokus Offenlegungen hier sind beide wirklich aufschlussreich, wenn man liest, was sie bestätigt haben, gegenüber dem, was sekundär verstärkt wurde – siehe unsere Railway-Breach-Aufschlüsselung als Beispiel dafür, beides zu trennen.

Siehe die vollständigen Vergleiche: Railyard vs. Railway und Migrating from Heroku.

FAQ

Wurde jede PaaS gehackt? Nein, und das behaupten wir nicht. Dieser Beitrag deckt zwei spezifische, bestätigte, gut dokumentierte Vorfälle ab – Railway (2026) und Heroku (2022) – nicht jede Plattform auf dem Markt.

Macht ein eigener Server einen Breach unmöglich? Nein. Die Control Plane einer Plattform muss deine Secrets immer noch irgendwo speichern, bevor sie deployt werden, und dieser Speicher ist ein Ziel bei jeder Architektur, Railyard eingeschlossen. Was sich ändert, ist, ob ein Bug in der geteilten Build-/Compute-Infrastruktur der Plattform zu einem Weg in die laufenden Live-Secrets anderer Kunden werden kann – bei einem BYO-Server-Modell gibt es keine geteilte Compute-Flotte, durch die sich dieser Bug bewegen könnte.

Was ist der eigentliche gemeinsame Faden zwischen Railways und Herokus Vorfällen? In beiden Fällen war der erste Zugangspunkt Infrastruktur, die die Plattform im Auftrag vieler Kunden gleichzeitig betreibt (Railways Build-/CI-Pipeline; Herokus interne Versionsverwaltung und Maschinenkonto-Zugangsdaten), und die Auswirkung erreichte Kunden, die mit der ursprünglichen Schwachstelle nichts zu tun hatten.

Quellen

• Security Disclosure: Wednesday October 21st – Railways eigener Blog
• Preliminary Report: Oct 21st Security Incident – Railways eigener Blog
• April 2022 Incident Review – Herokus eigener Blog
• Incident 2413 – Herokus eigene Statusseite
• Security alert: Attack campaign involving stolen OAuth user tokens – GitHubs eigener Blog
• Heroku Forces User Password Resets Following GitHub OAuth Token Theft – Sekundärberichterstattung