CVE-2026-66066: Kritische Schwachstelle in Ruby on Rails legt Secrets und Zugangsdaten offen

Die Maintainer von Ruby on Rails haben Sicherheitsupdates veröffentlicht, um eine schwerwiegende Schwachstelle in der Active Storage-Komponente zu beheben. Die als CVE-2026-66066 identifizierte Schwachstelle mit einem CVSS-Score von 9,5 ermöglicht es einem nicht authentifizierten Angreifer, beliebige Dateien vom Server zu lesen. Das größte Risiko besteht in der Offenlegung des SECRET_KEY_BASE und anderer Zugangsdaten, was die reale Möglichkeit eröffnet, Code aus der Ferne auszuführen und sich lateral zu anderen Systemen zu bewegen.

Active Storage deaktivierte die „unfuzzed“-Operationen von libvips nicht

Die Ursache des Problems liegt in der Interaktion zwischen Active Storage und der Bibliothek libvips, die zur Verarbeitung von Benutzer-Uploads verwendet wird. Innerhalb von libvips werden einige Operationen als „unfuzzed“ eingestuft – ein Begriff, der auf ihre Gefährlichkeit hinweist, wenn sie auf nicht vertrauenswürdige Inhalte angewendet werden. In solchen Fällen sollten diese Operationen deaktiviert werden. Active Storage tat dies jedoch nicht.

Ein speziell präpariertes Bild kann daher das Lesen beliebiger Dateien erzwingen, auf die der Anwendungsprozess zugreifen kann: Umgebungsvariablen, Konfigurationsdateien und vor allem den SECRET_KEY_BASE von Rails sowie die Zugangsdaten für Datenbanken, externe APIs und Cloud-Dienste. Für einen Angriff genügt es, dass ein nicht authentifizierter Benutzer ein Bild hochladen kann – eine bei vielen Webanwendungen übliche Voraussetzung.

Die libvips-Version ist entscheidend. Erst ab Version 8.13 bietet die Bibliothek eine explizite Steuerung, um die „unfuzzed“-Operationen zu deaktivieren. Frühere Versionen erlauben diesen Schutz nicht, weshalb das Update doppelt erforderlich ist: Active Storage muss gepatcht werden, um die Deaktivierung anzufordern, und libvips muss in der Lage sein, sie anzuwenden.

Vom Lesen von Dateien zur Codeausführung: Warum die Gefahr maximal ist

Das Lesen beliebiger Dateien ist bereits ein schwerwiegender Vorfall, doch hier kann sich der Schaden schnell vergrößern. Mit dem SECRET_KEY_BASE kann ein Angreifer Sitzungen fälschen, gültige Token generieren und in vielen Szenarien die Ausführung von Remotecode erlangen, indem er Serialisierungsmechanismen oder andere Framework-Funktionen ausnutzt. Die Zugangsdaten für externe Systeme (Datenbanken, Speicher, APIs) ebnen dann den Weg für laterale Bewegungen: Von der Rails-Anwendung aus kann man auf andere Komponenten der Infrastruktur übergreifen und so die Kompromittierung ausweiten.

Der CVSS-Score von 9,5 spiegelt genau diese Kette wider: einfacher Angriffsvektor (Bild-Upload), keine Authentifizierung erforderlich, extrem hohe Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. Laut Rapid7 wurden bis zum 30. Juli keine Fälle aktiver Ausnutzung im Netz festgestellt. Das Fehlen öffentlicher Exploits verringert jedoch nicht die Dringlichkeit: Die Zeit zwischen der Offenlegung und den ersten Angriffsversuchen kann auf wenige Stunden schrumpfen.

So sichern Sie Ihre Anwendung ab

Die Patches für Active Storage sind in den Versionen 7.2.3.2, 8.0.5.1 und 8.1.3.1 verfügbar. Wer eine unterstützte Version einsetzt, sollte das Update umgehend einspielen. Gleichzeitig muss libvips auf Version 8.13 oder höher aktualisiert werden: Ohne diesen Schritt wäre die Korrektur auf Rails-Seite wirkungslos, da die Bibliothek die gefährlichen Operationen nicht deaktivieren könnte.

Ein weiterer kritischer Schritt ist die Rotation der Secrets. War die Anwendung vor dem Update exponiert, müssen alle für den Prozess zugänglichen Zugangsdaten – Session-Keys, SECRET_KEY_BASE, API-Token, Datenbank-Passwörter, Cloud-Credentials – unverzüglich ausgetauscht werden. Das Einspielen des Patches ohne Rotation der Secrets würde die Tür für diejenigen offen lassen, die die Zugangsdaten bereits zuvor extrahiert haben könnten.

Schließlich empfiehlt es sich, die Anwendungs- und Systemprotokolle auf anomale Zugriffe oder verdächtige Bild-Uploads zu überprüfen, auch wenn die Art des Angriffs (Dateilesen) unter Umständen keine eindeutigen Spuren hinterlässt.