Critical Rails Flaw Lets Attackers Write Server Files via Crafted ImageMagick Uploads

A critical flaw in Ruby on Rails could allow an unauthenticated attacker to write arbitrary files on an app’s server by uploading a crafted file if the app processes uploads using ImageMagick. The Rails project disclosed the flaw in an advisory and fixed it in versions 8.1.4.1 and 8.0.5.2.

The flaw is in Active Storage, the part of Rails that handles file uploads. Some apps store uploaded files using Active Storage’s Disk service, which stores them on the server’s disk. In those apps, an attacker could also read any file the app can read.

Those files typically include the app’s secret_key_base and its credentials for other systems Reading them may in turn allow remote code execution or lateral movement into those systems

Rails rates the flaw 9.8 out of 10 on the CVSS scale. It is tracked as GHSA-f3w6-w445-fwh9 and does not yet have a CVE identifier.

ImageMagick selects a format handler, which it calls a coder, based on the file’s content. Some coders act on other files named inside the image, not on the image itself. Active Storage imposes no limits on which coders an upload can use, so the server’s own ImageMagick policy was the only limit.

The ImageMagick analyzer in Active Storage runs when a file is attached. Attaching the upload is enough to reach the flaw. The app does not have to make a variant (a transformed copy of the image) or a preview, or call analyze.

An uploaded SVG file reached ImageMagick’s MSL coder through that analyzer, according to the commit that fixed the flaw. MSL is a scripting coder that reads and writes files named by its script.

Rails said one attack chain was reported to it, but it does “not assume it is the only one that exists.” The advisory does not say whether the flaw has been exploited.

The flaw was reported through HackerOne by RyotaK, a researcher at GMO Flatt Security.

Which Rails Apps Are Affected

An app is affected only if all three of these are true:

• It uses ImageMagick for Active Storage image processing. That is the setting config.active_storage.variant_processor = :mini_magick, the default for apps on load_defaults 6.1 or earlier.
• Its ImageMagick security policy does not already block the coders involved. Rails says the policies that Debian and Ubuntu ship do not.
• It accepts file uploads from untrusted users.

To check the first condition, look at config.active_storage.variant_processor. If it is not set, the default depends on load_defaults: :mini_magick before 7.0, and :vips from 7.0 on. The same setting decides which library analyzes uploads, not only which one makes variants.

Every Active Storage version before 8.0.5.2 is affected, as are 8.1 versions before 8.1.4.1. Release series older than 8.0 are no longer supported, and Rails will not release fixed versions for them.

In July, Rails fixed a different critical Active Storage flaw, CVE-2026-66066, which affected apps that use libvips instead of ImageMagick. Apps using ImageMagick were not exposed to that flaw’s attack path, but they can be exposed to this one.

The same releases fix a second Active Storage flaw, GHSA-v924-7rp8-4mxh, which Rails rates high with a CVSS score of 8.8. Active Storage passed uploads to ImageMagick and FFmpeg under temporary file names that kept the uploaded file’s extension.

Those tools can pick a decoder from the extension when a file’s content does not show its format. So an attacker who chose an upload’s filename and declared its content type could choose the decoder that processes it.

What to Do

Rails strongly recommends upgrading as soon as possible. The two releases fix 21 security issues in total.

The fixed versions ship an ImageMagick security policy. MiniMagick is the Ruby gem Active Storage uses to call ImageMagick. In its default setup, every ImageMagick command it runs applies the policy, not only commands from Active Storage.

The policy blocks the MSL coder; coders that read or delete files other than the image; coders that fetch remote or local references or display them on a screen; every coder backed by Ghostscript, along with the gs delegate; and @filename indirection.

• Upgrade to Rails 8.1.4.1 or 8.0.5.2. Apps on :mini_magick also need mini_magick 5.1 or later, or they raise an error at boot. Rails 8.0 gets security fixes only until November 7, 2026, under its maintenance policy.
• Confirm that the app loads the new policy, as the Active Storage guide describes, by running bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'.
• Check whether the shipped policy reaches the app at all. It does not reach an app that replaces MiniMagick.cli_env after boot, clears the environment with MiniMagick.cli_prefix, or installs its own MiniMagick::Shell. Such an app must put the rules in ImageMagick’s system policy.
• Apps that use GraphicsMagick get no protection from the shipped policy, because GraphicsMagick does not read ImageMagick policies.
• Check the server’s own ImageMagick policy. The shipped policy adds to it rather than replacing it. A rule there that allows a coder, including a wildcard such as pattern="*", overrides the shipped policy’s block on that coder.
• If the app renders PDF or PostScript files through ImageMagick, re-allow the gs delegate and the coders it uses in the server’s policy.xml.
• If you cannot upgrade yet, copy the rules of the shipped policy, activestorage/lib/active_storage/image_magick/policy.xml, into ImageMagick’s system policy, such as /etc/ImageMagick-7/policy.xml. At a minimum, block the MSL coder, the Ghostscript coders, and the gs delegate. Rails also published the fix as patches for 8.1 and 8.0.
• Apps on release series older than 8.0 can use that workaround or upgrade to 8.0 or later.
• Rails’ workarounds for the second flaw only change how FFmpeg is used. None of them covers ImageMagick.
• If the app stores attachments with the Disk service, change secret_key_base and every other secret the app process can read. That includes the master key, everything config/credentials.yml.enc holds, storage and database credentials, and third-party tokens. Do not keep an exposed secret as a fallback.

The advisory does not explain how to check whether an app has already been targeted.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.