Lücke in Rails Active Storage: drei Einstellungen vor dem 7. November prüfen

Eine Lücke in Rails Active Storage (CVSS 9.8) erlaubt per Bild-Upload Dateien auf dem Server zu schreiben. Drei Einstellungen, Update und Rails-8.0-Frist.

Fast jede Rails-Anwendung, die ein Profilbild, ein Dokument oder ein Produktfoto entgegennimmt, leitet diese Datei durch Active Storage. Am 4. November 2026 hat das Rails-Team ein kritisches Security Advisory zu diesem Upload-Pfad veröffentlicht. In einigen gängigen Konfigurationen kann ein einziger präparierter Upload es einem nicht authentifizierten Angreifer ermöglichen, Dateien auf Ihren Server zu schreiben.

Ob Sie betroffen sind, hängt von drei Einstellungen ab, die sich leicht prüfen lassen. Dieser Artikel erklärt die Lücke, zeigt, wie Sie jede Einstellung prüfen, und beschreibt, was zu tun ist, wenn Sie heute noch nicht aktualisieren können. Am wichtigsten ist das für Teams auf Rails 8.0, denn der Security-Support für diesen Branch endet am 7. November 2026.

Worum es bei der Lücke geht

Wenn eine Datei angehängt wird, führt Active Storage einen Analyzer aus, der grundlegende Informationen wie die Bildabmessungen ausliest. Mit dem Prozessor :mini_magick übergibt dieser Analyzer die Datei an ImageMagick. ImageMagick unterstützt viele Formate über Module, die Coder heißen, und einige davon sind sehr mächtig: Der Fix-Commit zeigt, wie ein hochgeladenes SVG den MSL-Coder erreicht, ein Skriptformat, das in seinem Skript genannte Dateien lesen und schreiben kann. Active Storage hat nicht eingeschränkt, welche Coder ein Upload erreichen kann, sodass die ImageMagick-Policy des Servers der einzige Schutz war.

Zwei Details machen die Lücke gravierend. Erstens läuft der Analyzer schon beim Anhängen: Es braucht keine Variante, keine Vorschau und keinen expliziten analyze-Aufruf, die Annahme des Uploads genügt. Zweitens lassen sich Anwendungen, die Dateien mit dem Disk-Dienst speichern, zusätzlich dazu bringen, jede Datei zu lesen, die der Anwendungsprozess lesen kann. Dazu gehören secret_key_base und Zugangsdaten für andere Systeme, was zu Remote Code Execution oder Lateral Movement führen kann.

Gemeldet wurde die Lücke von RyotaK von GMO Flatt Security über HackerOne. Das Rails-Team weist darauf hin, dass eine Angriffskette gemeldet wurde, und geht nicht davon aus, dass es die einzige ist. Ob die Lücke bereits ausgenutzt wurde, sagt das Advisory nicht.

Der Drei-Bedingungen-Test

Betroffen sind Sie nur, wenn alle drei Bedingungen erfüllt sind. Prüfen Sie sie der Reihe nach; trifft eine davon nicht zu, greift diese Angriffskette nicht, ein Update bleibt aber trotzdem der richtige Schritt.

Bedingung	Wo nachsehen	Betroffen, wenn
1. Variant-Prozessor	config.active_storage.variant_processor und load_defaults	Er ist :mini_magick (der Standard bei load_defaults 6.1 oder älter)
2. ImageMagick-Policy	Die policy.xml des Servers	Sie blockiert MSL, die Ghostscript-Coder und den gs-Delegate nicht (die Standard-Policies von Debian und Ubuntu tun das nicht)
3. Wer hochladen darf	Ihre Upload-Formulare und APIs	Nicht vertrauenswürdige Nutzer können Dateien anhängen

1. Welchen Prozessor nutzt Active Storage?

Durchsuchen Sie Ihre Konfiguration und fragen Sie die laufende Anwendung ab:

grep -rn "variant_processor\|load_defaults" config/
bin/rails runner 'p Rails.application.config.active_storage.variant_processor'

Seit Rails 7.0 ist :vips der Standard, doch Anwendungen, die von älteren Versionen aktualisiert wurden, laden oft noch ältere Defaults oder setzen :mini_magick explizit. Prüfen Sie außerdem bundle info mini_magick: Ist das Gem in Ihrem Bundle, finden Sie heraus, wo es verwendet wird.

2. Blockiert Ihre ImageMagick-Policy die gefährlichen Coder?

Lassen Sie sich auf jedem Anwendungsserver und Worker die Policy anzeigen, die ImageMagick tatsächlich lädt:

magick -list policy      # ImageMagick 7
convert -list policy     # ImageMagick 6

Suchen Sie nach Regeln mit rights="none" für den MSL-Coder, die PostScript- und PDF-Coder sowie den gs-Delegate. Wenn Sie die mitgelieferte Policy von Debian oder Ubuntu unverändert nutzen, gehen Sie davon aus, dass sie nicht blockiert sind. Denken Sie daran, dass Container-Images und Worker-Hosts einen anderen ImageMagick-Build verwenden können als Ihre Webserver.

3. Können nicht vertrauenswürdige Nutzer Dateien hochladen?

Erfassen Sie jede Stelle, an der eine Datei attach, has_one_attached oder has_many_attached erreicht, einschließlich APIs, Direct Uploads und Admin-Tools, die Dateien von außen importieren. Eine öffentliche Registrierung mit Avatar-Feld gilt als nicht vertrauenswürdig.

Die Lösung: Update-Pfade je Branch

Die korrigierten Releases sind Rails 8.1.4.1 und Rails 8.0.5.2. Zusammen beheben sie 21 Sicherheitsprobleme und lohnen sich daher auch dann, wenn Sie von dieser Lücke nicht betroffen sind.

Ihr Branch	Was zu tun ist
8.1	Auf 8.1.4.1 aktualisieren
8.0	Jetzt auf 8.0.5.2 aktualisieren und dann den Umstieg auf 8.1 planen: Der Security-Support für 8.0 endet am 7. November 2026
7.2 und älter	Es wird kein Fix veröffentlicht. Wenden Sie den unten beschriebenen Policy-Workaround an und aktualisieren Sie auf 8.0 oder neuer

Anwendungen, die :mini_magick verwenden, benötigen außerdem mini_magick 5.1 oder neuer. Mit einer älteren Version wirft das korrigierte Release beim Booten einen Fehler. Aktualisieren Sie daher beide Gems gemeinsam und testen Sie den Bootvorgang im Staging:

bundle update rails mini_magick
bundle info activestorage
bundle info mini_magick

Die korrigierten Releases bringen eine eigene ImageMagick-Policy mit, prüfen Sie aber, ob sie ImageMagick auch tatsächlich erreicht. Sie greift nicht, wenn Ihre Anwendung MiniMagick.cli_env nach dem Booten ersetzt, MiniMagick.cli_prefix verwendet oder eine eigene MiniMagick::Shell installiert; solche Anwendungen brauchen die Regeln in der System-Policy. GraphicsMagick liest ImageMagick-Policies überhaupt nicht. Zudem ergänzt die mitgelieferte Policy die policy.xml Ihres Servers, statt sie zu ersetzen: Eine dortige Allow-Regel, auch ein Wildcard, hebt die Sperre also auf.

Dieselben Releases beheben eine zweite Lücke, GHSA-v924-7rp8-4mxh (CVSS 8.8). Active Storage übergab Uploads an ImageMagick und FFmpeg unter temporären Namen, die die ursprüngliche Dateiendung beibehielten. Ein Angreifer, der Dateinamen und deklarierten Content-Type kontrollierte, konnte so beeinflussen, welcher Decoder ausgeführt wurde. Die Rails-Workarounds für diese Lücke decken nur FFmpeg ab – ein weiterer Grund, zu aktualisieren, statt sich auf Workarounds zu verlassen.

Ein Muster, kein Einzelfall

Im Juli 2026 war CVE-2026-66066 eine separate kritische Lücke in Active Storage, die Anwendungen mit libvips betraf. Anwendungen auf ImageMagick waren über diesen Pfad nicht angreifbar, über diesen hier aber schon. Zwei kritische Lücken in vier Monaten, über beide unterstützten Bildbibliotheken, führen zur selben Lehre: Bildverarbeitung ist eine große Angriffsfläche, und Active Storage wendet sie auf Dateien von Fremden an, sobald diese angehängt werden.

Ein Wechsel des Prozessors allein ist keine Lösung. Was Sie schützt, ist, die Bildbibliothek als Teil Ihrer Angriffsfläche zu behandeln: Halten Sie sie wie das Framework gepatcht, schränken Sie sie per Policy ein und wissen Sie, auf welchen Hosts sie läuft. Gerade die ImageMagick-Policy ist eine Servereinstellung, die leicht vergessen wird, weil sie im Betriebssystem-Image liegt und nicht in Ihrem Anwendungscode.

Wenn Sie nicht sofort aktualisieren können

Rails hat außerdem Patch-Commits für 8.1 und 8.0 veröffentlicht. Bis Sie ein korrigiertes Release ausrollen können, arbeiten Sie diese Checkliste ab:

1. Ergänzen Sie die Mindestregeln aus dem Advisory in der System-Policy von ImageMagick auf jedem Host, der Uploads verarbeitet (zum Beispiel /etc/ImageMagick-7/policy.xml).
2. Stellen Sie sicher, dass keine Allow-Regel und kein Wildcard in derselben Datei sie aufhebt, und prüfen Sie das anschließend mit magick -list policy.
3. Wenn Sie PDF oder PostScript über ImageMagick rendern, lassen Sie den gs-Delegate und nur die benötigten Coder wieder zu und akzeptieren Sie, dass dadurch ein Restrisiko bleibt.
4. Beschränken Sie Uploads: Schränken Sie vorübergehend ein, wer Dateien anhängen darf, oder setzen Sie anonyme Uploads aus.
5. Wenn Sie den Disk-Dienst nutzen, planen Sie den Austausch von secret_key_base, des Master Keys und des Inhalts von config/credentials.yml.enc, der Zugangsdaten für Speicher und Datenbank sowie von Tokens für Drittanbieter. Behalten Sie kein offengelegtes Secret als Fallback.

Die im Advisory veröffentlichten Mindestregeln lauten:

<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}"/>

Alle Details finden Sie im Rails Security Advisory.

Wie LOGIQ helfen kann

LOGIQ unterstützt Teams, die Open-Source-Stacks auf Linux betreiben – vom Betriebssystem-Image bis zur Anwendungslaufzeit. Wenn Sie Hilfe bei der Prüfung der ImageMagick-Policies auf Ihren Servern oder bei der Planung des Umstiegs von einem Branch mit auslaufendem Support wünschen, sprechen Sie mit unserem Team.