Eine kritische Sicherheitslücke in Ruby on Rails erlaubt es Angreifern, über manipulierte Bild-Uploads beliebige Dateien auszulesen, auf die der Serverprozess Zugriff hat. Weil dabei auch die zentralen Schlüssel der Anwendung in fremde Hände geraten können, warnt das Rails-Team vor Folgeangriffen bis hin zur Ausführung von Schadcode. Abgesicherte Versionen stehen bereit, Betreiber sollten zügig handeln, Updates einspielen und ihre Schlüssel vorsorglich tauschen.

Die Schwachstelle steckt in Active Storage, der in Rails eingebauten Komponente für Datei-Uploads, und wird als CVE-2026-66066 geführt. Das Advisory des Rails-Teams stuft sie mit einem CVSS-Wert von 9,5 von 10 als kritisch ein. Entdeckt haben die Lücke unabhängig voneinander die Sicherheitsforscher André Baptista, Bruno Mendes und Rafael Castilho von Ethiack sowie RyotaK von GMO Flatt Security. Sie tauften die Angriffskette „KindaRails2Shell“.

Präparierte Bilder als Einfallstor

Mit Active Storage hängen Rails-Anwendungen hochgeladene Dateien an Datenbankobjekte, etwa Profilbilder oder Produktfotos. Aus Bildern erzeugt die Komponente auf Wunsch sogenannte Varianten, zum Beispiel verkleinerte Thumbnails. Die eigentliche Bildverarbeitung übernimmt dabei seit Rails 7.0 standardmäßig die C-Bibliothek libvips.

libvips liest und schreibt zahlreiche Dateiformate über Operationen, die teils auf Bibliotheken von Drittanbietern beruhen. Einen Teil davon stuft das Projekt selbst als „untrusted“ ein: Diese Operationen sind nicht ausreichend per Fuzzing getestet und gelten daher als ungeeignet für Dateien, die ein Angreifer kontrolliert. Genau sie schaltete Active Storage bislang nicht ab. Ein Angreifer kann deshalb eine präparierte Datei hochladen, die bei der Verarbeitung eine dieser kritischen Operationen auslöst.

Nach Angaben des Rails-Sicherheitsteams existiert mindestens eine Angriffskette, mit der sich sämtliche Dateien auslesen lassen, die der Rails-Prozess lesen kann, einschließlich seiner Umgebungsvariablen. Dort liegen in typischen Deployments der secret_key_base, mit dem Rails unter anderem Sitzungs-Cookies signiert, der RAILS_MASTER_KEY zum Entschlüsseln der hinterlegten Zugangsdaten sowie häufig Datenbankpasswörter und Schlüssel für Cloud-Speicher. Mit dieser Beute lassen sich Sitzungen fälschen, verschlüsselte Credentials öffnen und angebundene Dienste übernehmen. Das Advisory spricht deshalb von möglicher Remote Code Execution, auch wenn der Schadcode nicht zwingend direkt in der Bildverarbeitung ausgeführt wird.

Auch der Rails-Standardweg führt in die Lücke

Verwundbar ist eine Anwendung, wenn Active Storage libvips als Bildprozessor verwendet und nicht vertrauenswürdige Benutzer Bilder hochladen können. Ein öffentlicher Upload ist dafür nicht nötig, eine kostenlose Registrierung reicht. Das betrifft Avatare und Produktbilder ebenso wie Bildanhänge in Foren, Chats oder Ticketsystemen.

Eine frisch generierte Rails-Anwendung verarbeitet ohne zusätzliche Gems zwar noch keine Bilder und ist insofern zunächst nicht angreifbar. Der dokumentierte Standardweg zu Bildvarianten führt aber direkt in die verwundbare Konfiguration: Seit Rails 7.0 ist :vips der voreingestellte Prozessor, das von rails new erzeugte Dockerfile installiert libvips gleich mit, und das Gem image_processing, das die libvips-Anbindung ruby-vips als Abhängigkeit mitbringt, steht bis Rails 8.0 als auskommentierter Vorschlag im generierten Gemfile. Seit Rails 8.1 legt der Generator es sogar standardmäßig aktiv an. Wer Bild-Uploads samt Vorschaubildern anbietet, läuft also mit hoher Wahrscheinlichkeit auf dem betroffenen Pfad. Rails-6-Anwendungen sind nur bei manuell umgestellter Konfiguration verwundbar, dort war noch ImageMagick voreingestellt.

Welcher Prozessor tatsächlich aktiv ist, verrät ein Einzeiler:

bin/rails runner 'puts Rails.application.config.active_storage.variant_processor'

Gibt der Befehl vips aus, ist die Anwendung auf dem betroffenen Verarbeitungsweg. Das Rails-Team betont zudem, dass das Erzeugen von Varianten keine zusätzliche Voraussetzung ist: Active Storage untersucht hochgeladene Dateien auch von sich aus, etwa um Bildmaße zu bestimmen. Wer im eigenen Code keine variant– oder representation-Aufrufe findet, ist deshalb noch nicht auf der sicheren Seite.

Ausgelöst wird diese Analyse bereits davon, dass eine Datei per attach an einen Datensatz gehängt wird. Die entscheidende Frage lautet also nicht, ob es ein als Bild-Upload beschriftetes Formularfeld gibt, sondern ob nicht vertrauenswürdige Benutzer irgendeinen Weg erreichen, der ihre Datei anhängt. Ob dabei libvips zum Zug kommt, hängt am erkannten Dateityp, nicht an der Beschriftung des Feldes: Ein Formular für Dokumente zählt mit, sobald dort eine als Bild erkannte Datei landet.

Update plus aktuelles libvips

Geschlossen ist die Lücke in Rails 7.2.3.2, 8.0.5.1 und 8.1.3.1; betroffen sind alle früheren Versionen der jeweiligen Serien. Da Active Storage gemeinsam mit Rails aktualisiert wird, genügt ein bundle update rails auf die jeweilige Patch-Version. Für ältere Serien wie Rails 7.1, 7.0 oder 6.x gibt es keine korrigierten Versionen mehr, deren Sicherheitswartung ist ausgelaufen. Betreibern solcher Anwendungen bleibt nur der Umstieg auf eine unterstützte Serie oder übergangsweise der Workaround.

Der Rails-Patch allein reicht allerdings nicht: Die abgesicherten Versionen setzen mindestens libvips 8.13 voraus, denn erst seit dieser Version kann die Bibliothek ihre als „untrusted“ markierten Operationen blockieren. Mit einer älteren libvips-Version startet das gepatchte Active Storage absichtlich nicht und bricht beim Booten mit einer Exception ab. In Docker-Umgebungen gehört das libvips-Update daher ins Basis-Image, das anschließend neu gebaut und ausgerollt werden muss.

Wer nicht sofort aktualisieren kann, aber bereits libvips 8.13 oder neuer einsetzt, kann die riskanten Operationen übergangsweise selbst abschalten: entweder über die Umgebungsvariable VIPS_BLOCK_UNTRUSTED=1, gesetzt in der Prozess- oder Containerkonfiguration, bevor libvips initialisiert wird, oder ab ruby-vips 2.2.1 per Vips.block_untrusted(true) in einem Initializer. Für ältere libvips-Versionen existiert kein Workaround.

Schlüssel tauschen, nicht nur patchen

Ob eine Anwendung bereits angegriffen wurde, lässt sich kaum feststellen; das Advisory nennt keinen verlässlichen Indikator. Das Rails-Team empfiehlt betroffenen Betreibern daher, alle Geheimnisse als kompromittiert zu behandeln, die der Rails-Prozess lesen konnte: secret_key_base, den Master-Key samt aller in credentials.yml.enc gespeicherten Werte, Datenbank- und Storage-Zugangsdaten sowie Tokens externer Dienste.

Die Reihenfolge zählt: erst die gepatchte Version vollständig ausrollen, dann rotieren, sonst kann ein Angreifer die frischen Schlüssel gleich wieder mitlesen. Der Wechsel des secret_key_base macht bestehende Sitzungen ungültig, alle Benutzer müssen sich neu anmelden. Beim Tausch des Master-Keys müssen auch die Inhalte der Credentials erneuert werden; dieselben Passwörter lediglich mit einem frischen Schlüssel neu zu verschlüsseln hilft nicht, denn ein Angreifer kann sie bereits im Klartext besitzen.

Exploit-Details folgen Ende August

Die technischen Einzelheiten der Angriffskette hält das Rails-Team bewusst zurück und will sie spätestens am 28. August 2026 im Forum für Sicherheitsankündigungen veröffentlichen. Die Begründung: Details würden an der Update-Entscheidung nichts ändern, Angreifern aber die Arbeit erheblich erleichtern. Auch die Entdecker beschreiben ihre Funde bislang nur in Umrissen.

Warten sollte auf diese Veröffentlichung niemand. Die vorliegenden Informationen genügen, um zu klären, ob eine Anwendung betroffen ist, und das Update samt Schlüsselrotation anzustoßen. Versierte Angreifer können den Patch ohnehin schon jetzt mit den verwundbaren Versionen vergleichen.

(who)