Eine neue Rails Sicherheitslücke mit der Kennung CVE-2026-66066 zwingt Betreiber von Ruby-on-Rails-Anwendungen zum schnellen Handeln. Das Rails-Team hat die Lücke am 29. Juli 2026 offengelegt. Sie steckt in Active Storage und erlaubt es Angreifern im ungünstigsten Fall, beliebige Dateien vom Server zu lesen – inklusive der Geheimnisse, mit denen die Anwendung arbeitet. Sicherheitsforscher stufen den Fehler mit einem CVSS-Wert von 9,5 als kritisch ein.
Was die Rails Sicherheitslücke CVE-2026-66066 gefährlich macht
Der Kern des Problems liegt in der Bildverarbeitung. Active Storage nutzt in der Standardkonfiguration die Bibliothek libvips, um hochgeladene Bilder in Varianten umzuwandeln. libvips markiert bestimmte Operationen als „unfuzzed”, also als unsicher für nicht vertrauenswürdige Inhalte. Genau diese Operationen hat Active Storage bisher nicht deaktiviert. Lädt ein Angreifer eine präparierte Datei hoch und löst deren Verarbeitung aus, kann er darüber den Inhalt beliebiger Dateien auslesen.
Klartext ins Postfach
KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.
Besonders brisant: Zu den auslesbaren Daten gehört üblicherweise die Prozessumgebung mit dem secret_key_base und oft auch Zugangsdaten zu externen Systemen. Damit lässt sich der Angriff möglicherweise zu Remote Code Execution ausweiten oder auf andere Systeme übertragen. Die Forscher von Ethiack, die den Fehler zusammen mit GMO Flatt Security gemeldet haben, tauften ihn „KindaRails2Shell”.
Welche Anwendungen betroffen sind
Eine Anwendung ist verwundbar, wenn beide Bedingungen zutreffen: Sie verwendet libvips als Variant-Processor (Standard seit load_defaults 7.0) und sie erlaubt Bild-Uploads von nicht vertrauenswürdigen Nutzern. Betroffen sind laut Advisory diese Versionen:
- activestorage vor 7.2.3.2
- activestorage ab 8.0, vor 8.0.5.1
- activestorage ab 8.1, vor 8.1.3.1
Bislang gibt es keine bestätigten Berichte über eine breite Ausnutzung in freier Wildbahn. Entspannen sollte sich aber niemand: Nachdem Sicherheitsforscher den Angriff rekonstruiert und öffentlichen Proof-of-Concept-Code bereitgestellt hatten, zog das Rails-Umfeld die technischen Details samt Analyse-Werkzeugen vor und legte sie schon Ende Juli offen – Wochen vor dem ursprünglich für den 28. August geplanten Termin. Wer eine betroffene Anwendung betreibt, sollte deshalb nicht auf den nächsten regulären Wartungszyklus warten.
Was Betreiber jetzt tun sollten
Der wichtigste Schritt ist das Update auf eine der korrigierten Active-Storage-Versionen. Dabei muss libvips zwingend in Version 8.13 oder neuer vorliegen, sonst startet Active Storage bewusst nicht mehr. Wer nicht sofort updaten kann, hat zwei Notbehelfe: die Umgebungsvariable VIPS_BLOCK_UNTRUSTED setzen oder mit ruby-vips ab 2.2.1 in einem Initializer Vips.block_untrusted(true) aufrufen.
Weil ein Datei-Leak schon stattgefunden haben könnte, sollten Betreiber außerdem alle Geheimnisse rotieren, die der Anwendungsprozess lesen kann: secret_key_base, den Master-Key samt credentials.yml.enc, die Schlüssel des Active-Storage-Dienstes, die Datenbank-Zugangsdaten sowie Tokens zu Drittdiensten. Ein bereits abgeflossenes Geheimnis wird durch das Update allein nicht ungültig. Wie schnell aus einer offengelegten Lücke ein echter Angriff wird, zeigte zuletzt die GitLab-Sicherheitslücke mit RCE-Exploit.
Quellen
- Ruby on Rails Security Announcement (CVE-2026-66066)
- Rapid7: KindaRails2Shell – CVE-2026-66066
- SecurityWeek: Ruby on Rails patches critical vulnerability
Diese Analysen als Newsletter
Ein Mal pro Woche Klartext zu KI, Security & Crypto – direkt in dein Postfach.
Jetzt anmelden