Rails Active Storage enthält eine kritische ImageMagick-Lücke: GHSA-f3w6-w445-fwh9. Das Rails-Security-Advisory vom 4. November 2026 stuft sie mit CVSS 9.8 ein. Fix-Versionen sind activestorage 8.0.5.2 und 8.1.4.1; die Begleit-Releases fasst der Rails-Blog zusammen.
Betroffen sind Apps, die Active Storage mit ImageMagick (MiniMagick) verarbeiten, eine Policy ohne ausreichende Coder-Verbote fahren und Uploads von nicht vertrauenswürdigen Nutzern erlauben. Ein crafted Upload kann laut Advisory beliebige Dateien schreiben; bei Disk-Storage zusätzlich Dateien lesen, die der App-Prozess lesen darf – inklusive typischer Secrets.
Rails Active Storage: Impact ohne Exploit-Schritte
ImageMagick wählt Coder anhand des Dateiinhalts; manche Coder wirken auf referenzierte Dateien statt auf das Bild selbst. Active Storage begrenzte diese Coder zuvor nicht, und der Analyzer läuft bereits beim Anhängen – ohne extra Variant-/Preview-Aufruf. Das Advisory nennt eine gemeldete Angriffskette, geht aber ausdrücklich davon aus, dass es weitere geben kann. Details zum Ausnutzen gehören nicht in diesen Artikel; Betreiber sollen patchen, nicht nachbauen.
Die Fixed Releases liefern eine ImageMagick-Security-Policy und setzen deren Verzeichnis über MiniMagick.cli_env in MAGICK_CONFIGURE_PATH vor. Die Policy verweigert unter anderem den MSL-Coder, Coder/Delegates, die fremde Dateien lesen/löschen oder Remote-Referenzen holen, sowie Ghostscript-bezogene Coder und den gs-Delegate. Apps mit variant_processor = :mini_magick brauchen mini_magick ≥ 5.1.
Betroffene Versionen und Begleitpatches
Laut Advisory: activestorage < 8.0.5.2 sowie ≥ 8.1 und < 8.1.4.1. Die Rails-Releases 8.0.5.2 und 8.1.4.1 adressieren laut Blog insgesamt 21 Security-Themen – darunter weitere Active-Storage-, XSS-, DoS- und Session-Issues. Security-Support für die 8.0-Serie endet laut Blog am 7. November 2026; ältere Linien gelten als unsupported.
Workaround ohne sofortiges Gem-Upgrade: die Policy-Regeln aus dem Fixed Package in die System-policy.xml von ImageMagick übernehmen (mindestens MSL, Ghostscript-Coder und gs). Wer PostScript/PDF über ImageMagick rendert, muss passende Coder/Delegates in der Host-Policy bewusst wieder erlauben. GraphicsMagick liest ImageMagick-Policies nicht.
Was Betreiber jetzt tun sollten
Sofort auf gepatchtes activestorage gehen und mini_magick ≥ 5.1 absichern. Wenn Disk-Storage und untrusted Uploads im Spiel waren: secret_key_base, Master Key, Credentials, Storage-/DB-Zugänge und Drittanbieter-Tokens rotieren – das Advisory warnt ausdrücklich davor, exponierte Secrets als Fallback zu behalten. Upload-Oberflächen und Varianten-Pipelines gegen untrusted Content prüfen.
Bei code404zero haben wir verwandte Web-Security-Themen schon behandelt: CVE-2026-119977 WordPress Core, CVE-2026-81648, PHP2Shell und die PHP-Notfall-Patches. Gemeinsames Muster: Upload-/Update-Pfade bleiben Hochrisiko, sobald Processor und Secrets auf derselben Box liegen.
Weitere Fixes im selben Release-Zug
Die Rails-Releases vom 4. November adressieren laut Blog neben GHSA-f3w6-w445-fwh9 unter anderem eine High-Severity-Lücke zu Dateilesen/RCE in Active-Storage-Video-Previews und Bildverarbeitung (GHSA-v924-7rp8-4mxh), Strong-Parameters-Bypass, Remote-IP-Spoofing (nur 8.1), mehrere XSS in Action View, DoS-Vektoren und Session-/Cache-Themen. Wer nur die ImageMagick-Policy patched, aber auf alter Rails-Linie bleibt, verpasst diesen Bündel-Fix.
Security-Support für 8.0 endet am 7. November 2026 – wenige Tage nach dem Advisory. Teams auf 8.0 sollten den Sprung auf die gepatchte 8.0.5.2-Linie und den Upgrade-Pfad Richtung unterstützter Serie parallel planen. Unsupported ältere Major-Versionen erhalten laut Blog keine Fixes mehr.
Policy-Fallen in der Praxis
Wer MiniMagick.cli_env nach dem Boot ersetzt, die Umgebung per MiniMagick.cli_prefix leert oder eine eigene MiniMagick::Shell installiert, bekommt die mitgelieferte Policy laut Advisory nicht – und muss die Regeln in der System-Policy führen. PDF/PostScript-Rendering über ImageMagick verlangt bewusstes Re-Allow der Ghostscript-Pfade; pauschales Deny kann Produktionsfeatures brechen.
Debian-/Ubuntu-Standardpolicies schützen laut Advisory nicht ausreichend. Nach dem Upgrade: ImageMagick-Version, MiniMagick-Version, Active-Storage-Processor und Storage-Service (Disk vs. Cloud) in einem Runbook festhalten. Bei Verdacht auf Exposition: Incident-Playbook mit Secret-Rotation und Log-Review, ohne öffentliche Exploit-Details zu verbreiten.
Einordnung
Die Lücke ist kritisch bewertet und hat klare Fix-Versionen; eine CVE-ID nennt das Advisory zum Zeitpunkt der Veröffentlichung nicht (nur GHSA). Credit geht an den HackerOne-Researcher ryotak. Für Rails-Teams zählt Tempo beim Upgrade und – bei Disk-Storage – die Secrets-Rotation mehr als Debatten über CVSS-Feinheiten.
Disk-Storage und Secret-Hygiene
Das Advisory ist klar: Bei Disk-Service und möglichen untrusted Uploads Secrets rotieren – secret_key_base, Credentials-Master-Key, alles in credentials.yml.enc, Storage-/Datenbankzugänge und Dritttoken. Ein belassenes „altes“ Secret als Fallback unterläuft die Rotation. Cloud-Object-Storage reduziert den lokalen Dateilesepfad, ersetzt aber nicht den Patch der ImageMagick-Kette.
Monitoring nach dem Upgrade sollte fehlgeschlagene Analysen, ungewöhnliche Dateischreibversuche außerhalb erwarteter Upload-Pfade und ImageMagick-Policy-Verstöße in den Logs beobachten – ohne öffentliche PoC-Reproduktion. Credit im Advisory: HackerOne-Researcher ryotak.
Kurz: Rails Active Storage mit ImageMagick braucht den Sprung auf 8.0.5.2 bzw. 8.1.4.1. Primärquellen sind das GitHub-Advisory und der Rails-Release-Post vom 4. November 2026.
