Rails-Teams, die Bilder annehmen und sie mit ImageMagick weiterverarbeiten, haben an diesem Freitag Grund zur Eile. Eine Schwachstelle in Active Storage lässt präparierte Uploads beliebige Dateien auf dem Server schreiben – und, wenn das Projekt den Disk-Dienst nutzt, auch lesen. Der Fehler trifft alle Rails-8-Versionen bis einschließlich 8.0.5.1 beziehungsweise 8.1.4.0. Das Rails-Team hat gestern 8.0.5.2 und 8.1.4.1 veröffentlicht, das GitHub-Advisory GHSA-f3w6-w445-fwh9 trägt zusätzlich die CVE-Nummer CVE-2026-122006 mit einem CVSS-Wert von 9,8.

Was Active Storage macht und wo es schiefgeht

Active Storage ist Rails' eingebaute Abstraktion für Datei-Uploads – angefangen beim Speicher-Backend (lokale Platte, S3, GCS, Azure) bis zur Analyse hochgeladener Dateien. Für Bilder ruft Active Storage automatisch einen Analyzer auf, der Breite, Höhe und Metadaten ermittelt. Diese Analyse lief in den verwundbaren Versionen über ImageMagick, ohne dass die Policy des Werkzeugs auf die riskanten Coder (MSL, Ghostscript und die diversen Postscript-Varianten) eingeschränkt wurde.

ImageMagick wählt Coder anhand des Datei-Inhalts, nicht der Endung. Ein Angreifer kann einem Upload also Metadaten mitgeben, die ImageMagick dazu bringen, den MSL-Coder zu aktivieren – eine kleine Script-Sprache, mit der sich Dateien lesen und schreiben lassen. Noch gefährlicher ist der Ghostscript-Pfad: Über PS-, EPS- oder PDF-Interpretationen lassen sich beliebige Kommandos absetzen, soweit der laufende Prozess sie ausführen darf.

Der Haken: Die Analyse läuft bereits beim Anhängen der Datei, nicht erst bei der Varianten-Erzeugung. Es reicht also, eine präparierte Datei an irgendein Active-Storage-Attachment zu hängen. Eine Authentifizierung ist nicht nötig, sofern das Projekt einen öffentlichen Upload-Endpunkt bietet – etwa für Avatar-Bilder, Produktfotos oder Support-Anhänge.

Quellcode auf einem Laptop-Bildschirm als Symbolbild

Bild: Rust Code On Screen von Slashme, Lizenz CC0, via Wikimedia Commons.

Welche Versionen betroffen sind

Das Rails-Advisory nennt zwei Zweige:

  • Rails 8.0.x: alle Versionen unterhalb 8.0.5.2
  • Rails 8.1.x: alle Versionen ab 8.1 unterhalb 8.1.4.1

Die Fixes liefern eine mitgeführte policy.xml für ImageMagick aus und setzen voraus, dass mini_magick in Version 5.1 oder neuer verwendet wird. Konkret werden damit MSL-Coder, Ghostscript-Delegate und die Postscript-/PDF-Coder deaktiviert – das Set an Patterns, mit dem ImageMagick den Angriff überhaupt erst möglich machte.

Was du jetzt tun solltest

Für Rails-Projekte mit Active Storage gilt in dieser Reihenfolge:

  1. Gemfile aktualisieren. In Gemfile.lock kurz prüfen, welchen Zweig das Projekt fährt, dann:
    bundle update rails mini_magick
    Die Zielversion ist 8.0.5.2 beziehungsweise 8.1.4.1. mini_magick muss auf mindestens 5.1 stehen, sonst greift die neue ImageMagick-Policy nicht.
  2. ImageMagick-Policy härten – auch außerhalb von Rails. Wer nicht sofort patchen kann oder zusätzliche Dienste absichern will, kopiert die vom Advisory empfohlenen Regeln in die System-Policy (/etc/ImageMagick-7/policy.xml oder äquivalent):
    <policy domain="coder" rights="none" pattern="MSL"/>
<policy domain="delegate" rights="none" pattern="gs"/>
<policy domain="coder" rights="none"
        pattern="{PS,PS2,PS3,EPS,EPS2,EPS3,EPI,EPSF,EPSI,EPT,EPT2,EPT3,PDF,AI,EPDF,PDFA,POCKETMOD,XPS,PCL}"/>
    Das deaktiviert die gefährlichsten Coder und hilft gegen diese Klasse von Angriffen generell, nicht nur gegen den Rails-Fall.
  3. Hinweise auf Kompromittierung suchen. Rails-Logs auf unerwartete Dateischreib-Operationen durchsehen, Upload-Verzeichnisse auf Dateien mit untypischen Endungen oder Berechtigungen prüfen, und den secret_key_base rotieren, wenn das Projekt den Disk-Dienst nutzt und der Angreifer so config/credentials.yml.enc oder den Master-Key hätte lesen können.
  4. Mittelfristig: ImageMagick ablösen. Rails unterstützt seit einiger Zeit ruby-vips als Alternative. libvips ist schneller, speicherschonender und kommt ohne die berüchtigte Coder-Auswahl aus. Für neue Projekte lohnt sich der Umstieg aus Sicht der Angriffsfläche fast immer.

Serverseitige Bildverarbeitung bleibt ein Risiko

Die Schwachstelle reiht sich in eine lange Liste von ImageMagick-Vorfällen ein – ImageTragick aus dem Jahr 2016, der Ghostscript-SSRF 2018, immer wieder Delegate-Lücken. Der Grund ist nicht Pech, sondern Architektur: ImageMagick ist als flexibler Konverter konzipiert, der Quellformate anhand von Magic Bytes erkennt und an interne oder externe Werkzeuge weiterreicht. Diese Flexibilität wird zum Problem, sobald der Input von außen kommt. Projekte, die serverseitige Bildverarbeitung anbieten, sollten sich das klarmachen und entsprechend defensive Voreinstellungen fahren.

Die Entscheidung des Rails-Teams, die Standard-Policy im Gem auszuliefern, ist deshalb mehr als ein punktueller Fix: Sie verschiebt die Verantwortung weg vom Admin, der ImageMagick selten absichtlich konfiguriert, hin zum Framework-Default. Für Entwickler, die ihre Rails-Anwendung produktiv betreiben, ändert sich damit auch die Erwartung an eigene Dockerfiles und Build-Pipelines: Wer ImageMagick selbst installiert, muss nach dem Update sicherstellen, dass die mitgelieferte Policy auch aktiv ist – oder das Werkzeug ganz zu libvips umschwenken.

Für Betreiber von gehosteten Rails-Diensten

Wer Rails-Anwendungen für Kunden hostet, sollte die Lücke nicht an der Rails-Version festmachen, sondern an der ImageMagick-Policy des Systems. Ein zentral gehärtetes policy.xml auf der Host-Ebene wirkt für alle darauf laufenden Anwendungen, unabhängig davon, ob sie aktuell gepatcht sind. Das ist kein Ersatz für Updates, aber ein wirksamer Zweit-Riegel – gerade in Multi-Tenant-Setups, in denen nicht jeder Mandant im selben Tempo aktualisiert.

Zu guter Letzt: Der Disk-Dienst ist bequem, aber für produktive Rails-Anwendungen die schlechtere Wahl. Er legt Uploads direkt neben Code und Konfiguration ab und erweitert damit im Angriffsfall den Zugriffsradius auf config/credentials.yml.enc, .env-Dateien und Logs. Ein Objektspeicher (S3, MinIO, Hetzner Object Storage) trennt diese Pfade sauber und reduziert den Schaden, wenn eine Lücke wie diese einmal zuschlägt.

Quellen

Bildnachweis