Railway-Sicherheitsvorfall: die kurze Antwort

Der Plattformanbieter Railway hat am 21. Oktober 2026 gemeldet, dass Unbefugte möglicherweise auf verschlüsselt gespeicherte Umgebungsvariablen von Kunden zugegriffen und bei einem Teil davon die entschlüsselten Inhalte erlangt haben. In solchen Variablen können Passwörter und API-Schlüssel liegen. Railway empfiehlt, alle dort gespeicherten Umgebungsvariablen sofort zu erneuern. Am selben Tag wurde die KI-Software LiteLLM mit Schadcode ausgeliefert, der ebenfalls Zugangsdaten abgreift.

Wie schnell du nach einem solchen Vorfall reagieren kannst, hängt wesentlich davon ab, ob du weißt, wo deine Zugangsdaten überall liegen.

In diesem Artikel findest du, was die Anbieter selbst mitteilen, was du daraus lernen kannst und welche Schritte du für dein Unternehmen vorbereiten solltest, auch wenn du weder Railway noch LiteLLM nutzt.

Was bei Railway passiert ist

Railway ist eine Cloud-Plattform für den Betrieb von Anwendungen und Datenbanken. Konfiguration und Zugangsdaten können Kunden dort als Umgebungsvariablen hinterlegen.

Laut der Sicherheitsmeldung im Railway-Blog bemerkte das Unternehmen auffällige Aktivitäten an den Systemen, die diese Variablen speichern. Unbefugte könnten auf die verschlüsselten Variablen und bei einem Teil auf die entschlüsselten Inhalte zugegriffen haben. Railway empfiehlt allen Kunden vorsorglich, sämtliche dort gespeicherten Umgebungsvariablen einschließlich API-Schlüsseln sowie Zugangsdaten für private Registries sofort zu erneuern und die Protokolle der Dienste auf ungewöhnliche Aktivitäten zu prüfen.

Nach erster Analyse von Railway ist möglicherweise nur ein Teil der Kunden betroffen. Bestätigte Fälle will das Unternehmen direkt per E-Mail informieren.

Die Statusseite dokumentiert diese Schritte (alle Zeiten UTC):

  • 21. Oktober, 07:24: erste Störungsmeldung. Um 09:28 meldete Railway, dass neue Builds in allen Regionen pausiert waren.
  • 21. Oktober, 21:59: Sicherheitshinweis mit der Empfehlung, alle in Railway gespeicherten Umgebungsvariablen zu widerrufen.
  • 22. Oktober, ab 03:32: Builds wurden stufenweise wieder freigegeben, zunächst für Enterprise-, ab 06:29 auch für Pro-Kunden.
  • 22. Oktober, 04:17: Railway meldete, alle Railway-API-Tokens ungültig gemacht zu haben. Laut Update von 17:00 blieben vor dem Vorfall erstellte API- und Projekt-Tokens ungültig.

Stand des Abrufs: 22. Oktober 2026, 21:40 UTC. Laut dem jüngsten Update von 21:08 UTC waren Builds wieder für Hobby-Konten verfügbar, mit voraussichtlich längeren Deployments; Free- und Trial-Konten sollten folgen. Builds und Deployments für Pro und Enterprise starteten normal, konnten aber länger dauern. Neue Anmeldungen waren weiter pausiert, und der Vorfall war weiterhin als „Identified“ geführt.

Auf der Statusseite verlinkt Railway außerdem Leitfäden, unter anderem zu Datenbank-Zugangsdaten, GitHub, Stripe und KI-Anbietern sowie zur Prüfung von Konten bei AWS und Google Cloud.

Auch AthenaRun ist Kunde von Railway und hat die dort hinterlegten Zugangsdaten nach der Meldung erneuert.

Am selben Tag: LiteLLM

LiteLLM ist eine Open-Source-Software, über die Anwendungen KI-Modelle verschiedener Anbieter einheitlich ansprechen. Laut eigenem Vorfallbericht wurden am 21. Oktober kompromittierte Pakete der Version 1.107.0 auf PyPI und Container-Images auf Docker Hub und GHCR ausgeliefert. Auch die beweglichen Tags latest, main-latest und main-stable verwiesen zeitweise auf betroffene Images. Die Artefakte waren laut LiteLLM zwischen 11:39 und 14:20 UTC im Umlauf; die private Enterprise-Version war nicht betroffen.

Nach der Analyse von Aikido sammelt der Schadcode unter anderem Cloud-Zugangsdaten, gespeicherte Passwörter, SSH-Schlüssel, Umgebungsvariablen und die in LiteLLM hinterlegten API-Schlüssel der KI-Anbieter. Zusätzlich ermöglicht er Fernzugriff auf betroffene Systeme.

LiteLLM empfiehlt die Bereinigung beziehungsweise den Neuaufbau betroffener Umgebungen und nennt 1.106.2 als vorerst zu verwendende Version. Ein bloßes Downgrade reicht nicht: Laut Anbieter kann jeder Python-Start in der betroffenen Umgebung, auch der Paketmanager pip, den Schadcode erneut ausführen. Alle Zugangsdaten, die der betroffene Rechner erreichen konnte, sollen erneuert werden.

Weder Railway noch LiteLLM stellen in ihren Meldungen einen Zusammenhang zwischen den beiden Vorfällen her. Ebenfalls am 21. Oktober veröffentlichte das PHP-Projekt Sicherheitsupdates für zwei kritische Lücken. Was dieser separate Vorfall für ältere Systeme bedeutet, steht in PHP2Shell: Was die PHP-Sicherheitslücke für ältere Systeme bedeutet.

Gemeinsames Thema beider Vorfälle sind Zugangsdaten, besonders Schlüssel für KI-Dienste. Wer einen gestohlenen KI-Schlüssel nutzt, lässt Anfragen auf fremde Rechnung laufen. Im Leitfaden zu unerwarteter OpenRouter-Nutzung beschreibt Railway, wie ein abgeflossener Schlüssel direkt das vorausbezahlte Guthaben verbraucht.

Was du daraus lernen kannst

  1. Inventar vor dem Ernstfall. Halte fest, wo Zugangsdaten verwendet werden, wer sie erneuern kann und welche Dienste davon abhängen. Beziehe alte Projekte, Testumgebungen und Skripte ein. Bei vermutetem Abfluss darf eine noch unvollständige Liste den nötigen Widerruf nicht verzögern. Auch OWASP empfiehlt die sofortige Sperrung offengelegter Schlüssel.
  2. Deaktivieren statt löschen, wo der Anbieter das anbietet. Railways Leitfäden raten etwa bei OpenRouter und AWS dazu: Der Schlüssel ist sofort gesperrt, sein Verlauf bleibt für die Prüfung erhalten. Sichere relevante Protokolle und Nutzungsdaten; ein neuer Schlüssel allein macht den alten nicht ungültig.
  3. Verweise statt kopierter Werte. Zentrale Geheimnisverwaltung und Verweise verringern die Zahl der Stellen, die du ändern musst. Automatisch abgeschlossen ist eine Rotation damit nicht: Bei Railway müssen auch Variablenänderungen bereitgestellt werden, damit Anwendungen sie verwenden. Prüfe danach, ob die Dienste mit den neuen Zugangsdaten funktionieren.
  4. Datenbanken nicht öffentlich erreichbar machen, wenn es nicht nötig ist. Private Verbindungen begrenzen den Zugriff aus dem Internet. Ein abgeflossenes Passwort musst du trotzdem ersetzen: Ein Angreifer könnte auch über eine kompromittierte Anwendung zugreifen.
  5. Plattform-Abhängigkeit einplanen. Muss eine Anwendung neu bereitgestellt werden, um neue Zugangsdaten zu verwenden, kann ein Deployment-Stopp das verhindern. Der Widerruf alter Schlüssel kann dann Dienste unterbrechen. Plane diesen Konflikt vorher ein; ein laufender Missbrauch darf nicht auf die Wiederherstellung der Plattform warten.
  6. Nutzung sichtbar machen. Prüfe bei KI-Anbietern, Zahlungsdiensten und Cloud-Konten die verfügbaren Nutzungs- und Abrechnungsdaten und richte passende Warnungen ein. Ungewöhnliche Nutzung ist ein Anlass zur Prüfung und gegebenenfalls zum Sperren betroffener Schlüssel.
  7. Altlasten abbauen. Entferne ungenutzte Zugangsdaten und lege fest, wer jedes laufende System betreut. Systeme ohne Updates brauchen eine Entscheidung über Weiterbetrieb, Absicherung oder Ablösung. So wird die Bestandsaufnahme im nächsten Vorfall leichter.

Was du jetzt prüfen solltest

  • Railway-Kunde? Alle dort gespeicherten Umgebungsvariablen nach den Anbieterhinweisen erneuern und alte Schlüssel sperren; auch Zugangsdaten für private Registries berücksichtigen. Prüfe die verbundenen Cloud-Konten auf auffällige Zugriffe und kontrolliere, ob neue Zugangsdaten tatsächlich im laufenden Dienst angekommen sind. Ungültige Railway-API- und Projekt-Tokens für Automatisierungen müssen ersetzt werden.
  • LiteLLM im Einsatz? Prüfen, ob kompromittierte Pakete der Version 1.107.0 installiert oder betroffene Container-Images ausgeführt wurden, auch über bewegliche Tags. Wenn ja: die Umgebung als kompromittiert behandeln, nach der Anbieteranleitung bereinigen oder neu aufbauen und alle für sie erreichbaren Zugangsdaten erneuern.
  • Weder noch? Dann ist jetzt ein guter Zeitpunkt für die Liste aus Punkt 1: Welche Zugangsdaten hat dein Unternehmen, wo werden sie verwendet, wer kann sie erneuern, und was fällt aus, wenn du sie widerrufst?

Wo AthenaRun hier steht

Wir entwickeln Individualsoftware für den Mittelstand und lösen Altsysteme ab, die keine Updates mehr bekommen. Zum Angebot gehören Hosting in der EU und die vollständige Übergabe des Quellcodes. Wie eine Ablösung im Parallelbetrieb abläuft, steht auf der Seite Altsystem ablösen.

Wenn du nach diesem Vorfall feststellst, dass in deinem Unternehmen Systeme laufen, die niemand mehr richtig kennt: Erstgespräch anfragen. Wir schauen uns die Lage mit dir an und sagen dir auch, wenn wir nicht der richtige Partner sind.

Weiterlesen im Wissen-Hub

Wie selbstgebaute Anwendungen in Fachabteilungen geregelt werden können, steht in Governance-Rahmen für selbstgebaute Fachabteilungs-Anwendungen: Rollen, Freigaben, Protokollierung. Mit welchen Kosten du bei einer Ablösung rechnen solltest, zeigt Was kostet die Ablösung eines Altsystems ungefähr?.