Rails Active Storage flaw: check three settings before November 7

A CVSS 9.8 Rails Active Storage flaw lets one image upload write files on your server. Check three settings, upgrade, and mind the Rails 8.0 deadline.

Almost every Rails application that accepts a profile picture, a document or a product photo sends that file through Active Storage. On November 4, 2026, the Rails team published a critical advisory for that upload path. In some common setups, one crafted upload can let an unauthenticated attacker write files on your server.

Whether you are exposed depends on three settings that are easy to check. This article explains the flaw, shows how to check each setting, and lists what to do if you cannot upgrade today. It matters most for teams on Rails 8.0, because security support for that branch ends on November 7, 2026.

What the flaw is

When a file is attached, Active Storage runs an analyzer to read basic facts such as image dimensions. With the :mini_magick processor, that analyzer hands the file to ImageMagick. ImageMagick supports many formats through modules called coders, and some of them are powerful: the fix commit shows an uploaded SVG reaching the MSL coder, a scripting format that can read and write files named in its script. Active Storage did not limit which coders an upload could reach, so the server’s ImageMagick policy was the only protection.

Two details make this serious. First, the analyzer runs on attach, so no variant, preview or explicit analyze call is needed: accepting the upload is enough. Second, applications that store files with the Disk service can also be made to read any file the application process can read. That includes secret_key_base and credentials for other systems, which can lead to remote code execution or lateral movement.

The advisory was reported by RyotaK of GMO Flatt Security through HackerOne. The Rails team notes that one attack chain was reported and that they do not assume it is the only one. The advisory does not say whether the flaw has been exploited.

The three-condition exposure test

You are affected only when all three conditions hold. Check them in order; if any one is false, this attack chain does not apply, although upgrading is still the right move.

Condition	Where to look	Exposed when
1. Variant processor	config.active_storage.variant_processor and load_defaults	It is :mini_magick (the default for load_defaults 6.1 or earlier)
2. ImageMagick policy	The server’s policy.xml	It does not block MSL, the Ghostscript coders and the gs delegate (the default Debian and Ubuntu policies do not)
3. Who can upload	Your upload forms and APIs	Untrusted users can attach files

1. Which processor does Active Storage use?

Search your configuration and ask the running application:

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

Since Rails 7.0 the default is :vips, but applications that were upgraded from older versions often still load older defaults or set :mini_magick explicitly. Also check bundle info mini_magick: if the gem is in your bundle, find out where it is used.

2. Does your ImageMagick policy block the dangerous coders?

List the policy that ImageMagick actually loads on each application server and worker:

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

Look for rules with rights="none" for the MSL coder, the PostScript and PDF coders, and the gs delegate. If you use the packaged Debian or Ubuntu policy unchanged, assume they are not blocked. Remember that container images and worker hosts may run a different ImageMagick build from your web servers.

3. Can untrusted users upload files?

List every place a file reaches attach, has_one_attached or has_many_attached, including APIs, direct uploads and admin tools that import files from outside. Public sign-up with an avatar field counts as untrusted.

The fix: upgrade paths per branch

The fixed releases are Rails 8.1.4.1 and Rails 8.0.5.2. Together they fix 21 security issues, so they are worth installing even if you are not exposed to this one.

Your branch	What to do
8.1	Upgrade to 8.1.4.1
8.0	Upgrade to 8.0.5.2 now, then plan the move to 8.1: security support for 8.0 ends on November 7, 2026
7.2 and older	No fix will be released. Apply the policy workaround below and upgrade to 8.0 or later

Applications that use :mini_magick also need mini_magick 5.1 or later. With an older version the fixed release raises an error at boot, so update both gems together and test the boot in staging:

bundle update rails mini_magick
bundle info activestorage
bundle info mini_magick

The fixed releases ship their own ImageMagick policy, but check that it actually reaches ImageMagick. It does not apply if your application replaces MiniMagick.cli_env after boot, uses MiniMagick.cli_prefix, or installs its own MiniMagick::Shell; those applications need the rules in the system policy. GraphicsMagick does not read ImageMagick policies at all. The shipped policy also adds to your server’s policy.xml rather than replacing it, so an allow rule there, including a wildcard, overrides the block.

The same releases fix a second flaw, GHSA-v924-7rp8-4mxh (CVSS 8.8). Active Storage passed uploads to ImageMagick and FFmpeg under temporary names that kept the original file extension, so an attacker who controlled the filename and declared content type could influence which decoder ran. The Rails workarounds for this one cover FFmpeg only, which is one more reason to upgrade rather than rely on workarounds.

A pattern, not a one-off

In July 2026, CVE-2026-66066 was a separate critical Active Storage flaw that affected applications using libvips. Applications on ImageMagick were not exposed to that path, but they are exposed to this one. Two critical flaws in four months, through both supported image libraries, point to the same lesson: image processing is a large attack surface, and Active Storage runs it on files from strangers the moment they are attached.

Switching processors is not a fix on its own. What protects you is treating the image library as part of your attack surface: keep it patched like the framework, restrict it with a policy, and know which hosts run it. The ImageMagick policy, in particular, is a server setting that is easy to forget, because it lives in the operating system image rather than in your application code.

If you cannot upgrade immediately

Rails also published patch commits for 8.1 and 8.0. Until you can deploy a fixed release, work through this checklist:

1. Add the minimum rules from the advisory to ImageMagick’s system policy on every host that processes uploads (for example /etc/ImageMagick-7/policy.xml).
2. Make sure no allow rule or wildcard in the same file overrides them, then confirm with magick -list policy.
3. If you render PDF or PostScript through ImageMagick, re-allow the gs delegate and only the coders you need, and accept that this keeps some risk.
4. Gate uploads: temporarily restrict who can attach files, or pause anonymous uploads.
5. If you use the Disk service, plan to rotate secret_key_base, the master key and the contents of config/credentials.yml.enc, storage and database credentials, and third-party tokens. Do not keep an exposed secret as a fallback.

The minimum rules published in the advisory are:

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

Read the full details in the Rails security advisory.

How LOGIQ can help

LOGIQ supports teams that run open source stacks on Linux, from the operating system image to the application runtime. If you want help checking ImageMagick policies across your servers, or planning the move off a branch that is leaving support, talk to our team.