Rails Active Storage: Kritische Upload-Lücke über ImageMagick erlaubt Dateizugriff

Das Rails-Projekt hat am 4. November 2026 eine kritische Lücke in Active Storage veröffentlicht, der Upload-Komponente von Ruby on Rails. Über eine präparierte Datei kann ein nicht angemeldeter Angreifer beliebige Dateien auf den Server schreiben, wenn die Anwendung Uploads mit ImageMagick verarbeitet. Behoben ist das Problem in Rails 8.1.4.1 und 8.0.5.2, das Advisory GHSA-f3w6-w445-fwh9 nennt CVSS 9.8, eine CVE-Nummer gibt es noch nicht.

Von dieser Lücke sind viele Rails-Anwendungen nicht betroffen: Ab load_defaults 7.0 ist libvips der Standard, sofern der Variant-Prozessor nicht ausdrücklich auf ImageMagick steht. Gefährdet sind Anwendungen, die ImageMagick verwenden und Uploads von nicht vertrauenswürdigen Nutzern annehmen. Für sie ist das Update dringend, und wer Anhänge mit dem Disk-Service von Active Storage speichert, muss zusätzlich Schlüssel austauschen. Sinnvoll ist das Update für alle Anwendungen mit Uploads, weil eine zweite Lücke auch die Video- und Audioanalyse betrifft.

Was ist passiert?

ImageMagick wählt den Formatbearbeiter, Coder genannt, anhand des Dateiinhalts. Einige Coder verarbeiten nicht das Bild selbst, sondern Dateien, die im Bild genannt werden. Laut Advisory hat Active Storage keinen dieser Coder eingeschränkt. Weil der ImageMagick-Analyzer schon beim Anhängen einer Datei läuft, genügt der Upload: Eine Vorschau, eine Bildvariante oder ein Aufruf von analyze ist nicht nötig. Speichert die Anwendung Anhänge mit dem Disk-Service, kann der Angreifer zusätzlich jede Datei lesen, die der Anwendungsprozess lesen darf.

Dazu gehören laut Rails typischerweise secret_key_base und Zugangsdaten für andere Systeme, was zu Codeausführung oder zum Weitergehen auf diese Systeme führen kann. Rails wurde eine konkrete Angriffskette gemeldet, geht aber nicht davon aus, dass es die einzige ist. Gemeldet hat die Lücke der Forscher RyotaK über HackerOne.

Wer ist betroffen?

Eine Anwendung ist laut Advisory nur betroffen, wenn alle drei Bedingungen zutreffen:

• Active Storage verarbeitet Bilder mit ImageMagick, also config.active_storage.variant_processor = :mini_magick. Das ist der Standard für Anwendungen mit load_defaults 6.1 oder älter.
• Die ImageMagick-Sicherheitsrichtlinie des Servers sperrt die betroffenen Coder nicht. Die Richtlinien, die Debian und Ubuntu mitliefern, tun das laut Rails nicht.
• Die Anwendung nimmt Uploads von nicht vertrauenswürdigen Nutzern an.

Verwundbar sind alle activestorage-Versionen vor 8.0.5.2 sowie 8.1 vor 8.1.4.1. Reihen vor 8.0 werden laut Wartungsrichtlinie von Rails nicht mehr unterstützt und erhalten keine neuen Versionen. Für sie bleiben der Workaround über die System-Richtlinie oder ein Upgrade. Rails 8.0 erhält Sicherheitskorrekturen nur noch bis zum 7. November 2026.

Wie kritisch ist das?

Rails stuft die Lücke als kritisch mit CVSS 9.8 ein: Angriff über das Netz, keine Anmeldung, keine Mitwirkung eines Nutzers nötig. Ob die Lücke bereits ausgenutzt wird, sagt das Advisory nicht. Dieselben Releases schließen eine zweite Active-Storage-Lücke (GHSA-v924-7rp8-4mxh, CVSS 8.8): Hochgeladene Dateien behielten in temporären Dateinamen ihre Endung. So konnte ein Angreifer mit Nutzerkonto über Dateiname und angegebenen Inhaltstyp bestimmen, welcher Decoder von ImageMagick oder FFmpeg die Datei verarbeitet, wenn der Inhalt das Format nicht selbst verrät.

Was sollten Admins jetzt tun?

• Inventar: in jeder Rails-Anwendung config.active_storage.variant_processor und load_defaults prüfen. Ist kein Prozessor gesetzt, entscheidet load_defaults.
• Update: auf Rails 8.1.4.1 oder 8.0.5.2 aktualisieren. Mit :mini_magick ist mini_magick 5.1 oder neuer nötig, sonst startet die Anwendung nicht.
• Richtlinie kontrollieren: Die neuen Versionen bringen eine eigene ImageMagick-Richtlinie mit. Der Active-Storage-Guide nennt dafür als Prüfung bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'.
• Ohne sofortiges Update: die Regeln der mitgelieferten Richtlinie in die System-Richtlinie übernehmen, etwa /etc/ImageMagick-7/policy.xml, mindestens MSL, die Ghostscript-Coder und den Delegate gs sperren. Unter Debian und Ubuntu liegt die Datei je nach Version auch unter /etc/ImageMagick-6/.
• Einschränkungen: Wer PDF oder PostScript über ImageMagick rendert, muss gs und die nötigen Coder in der eigenen policy.xml wieder erlauben. Anwendungen mit eigenem MiniMagick.cli_env, MiniMagick.cli_prefix oder eigener Shell erhalten die mitgelieferte Richtlinie nicht, GraphicsMagick liest sie gar nicht.
• Disk-Service: secret_key_base, Master-Key, alle Einträge in config/credentials.yml.enc, Datenbank- und Speicherzugänge sowie Tokens von Drittanbietern erneuern.

Einordnung für Unternehmen

Betroffen sind vor allem ältere oder lange gepflegte Rails-Anwendungen mit Upload-Funktion, etwa Kundenportale oder interne Werkzeuge. Wer selbst gehostete Software auf Rails-Basis betreibt, sollte beim Hersteller nachfragen oder dessen Hinweise abwarten, ob die eigene Konfiguration ImageMagick nutzt. Wie sich eine bereits erfolgte Ausnutzung erkennen lässt, beschreibt das Advisory nicht. Bei Disk-Speicherung verlangt Rails ohnehin den Austausch aller Schlüssel, alte Schlüssel sollen nicht als Rückfallebene bleiben.

Passende Anleitungen auf S-EDV

• CVE-2026-66066: Kritische Ruby on Rails Lücke erlaubt Dateizugriff und RCE
• Linux-Server härten nach CIS-Benchmark: Praxisplan für KMU (Debian/Ubuntu)

Quellen

• Rails: Advisory GHSA-f3w6-w445-fwh9 zu ImageMagick in Active Storage
• Rails: Advisory GHSA-v924-7rp8-4mxh zu Dateiendungen
• Rails: Active-Storage-Guide mit ImageMagick-Richtlinie
• Rails: Konfigurations-Guide mit Standardwerten von load_defaults
• Rails: Wartungsrichtlinie
• The Hacker News: Bericht zur Rails-Lücke