Rails ImageMagick upload flaw can let attackers write server files

An upload form looks like a place where customers send you a photo. For some Ruby on Rails apps, it can also pass instructions to software on your server. The Rails project published an advisory about this flaw this week.

What happened

The Rails security team tracks the flaw as GHSA-f3w6-w445-fwh9. It affects Rails apps that use ImageMagick, a common tool for reading and resizing images. A stranger with no login could upload a crafted file. The server might then write files of the attacker's choosing.

Some apps keep uploads on the server's own disk, through the Active Storage Disk service. In those apps, the attacker might also read files that the app itself can read. Two of the things such files typically hold are the app's secret_key_base, which protects its sessions and signed data, and the passwords it uses to reach other systems. Stolen, they could lead to remote code execution or a break-in at those linked systems.

The Hacker News reports that Rails rates the flaw 9.8 on a 10-point scale, the CVSS standard for scoring severity. The flaw has no CVE number yet. Nothing in the advisory says attackers have used it. It also gives no test for finding out whether your app was hit.

How the flaw works

ImageMagick looks inside a file to decide which handler should open it. It calls these handlers coders. A few of them do more than read the image. They act on other files that the image names.

Active Storage is the part of Rails that manages uploads. It put no limits on which coders could run. Its ImageMagick analyzer also runs the moment a file is attached. No thumbnail or preview is needed.

The Hacker News points to the fixing commit. It shows that an uploaded SVG file could reach a coder called MSL. MSL is a scripting format whose scripts can read and write files. Rails has one reported attack and says it does "not assume it is the only one that exists."

The guard sat outside the app

Here is the idea worth keeping. Because Active Storage set no limits, the only brake was the ImageMagick policy on the host server. The Hacker News makes this point. Rails says the policies packaged for Debian and Ubuntu do not block the coders involved.

So an app team's risk depended on a settings file that may sit with a different team. The developer who built the upload form may never have opened it. The operations team that owns it may not have known uploads could reach it.

The fix moves the guard into the framework. Fixed versions ship their own ImageMagick policy. They tell each ImageMagick process started by MiniMagick to use it. MiniMagick is the Ruby gem Rails uses to call ImageMagick.

The new policy bans MSL scripting. It bans coders that read or delete other files. It bans anything built on Ghostscript, and @filename shortcuts. The host's own rules still apply. The new rules stack on top of them.

Who is affected

Rails lists three conditions, and an app must meet all of them. First, it uses ImageMagick for Active Storage, which is the :mini_magick setting. Second, the host's ImageMagick settings do not already block the risky coders. Third, it accepts uploads from untrusted users.

The :mini_magick setting is the default for apps on load_defaults 6.1 or earlier. Active Storage versions before 8.0.5.2 are affected. The 8.1 line is affected too, up to but not including 8.1.4.1. Rails will not release fixes for series older than 8.0.

The Hacker News recalls a separate July flaw, CVE-2026-66066. It touched apps that use libvips instead of ImageMagick. The July flaw hit libvips apps and left ImageMagick apps alone. This one reaches ImageMagick apps, so neither choice of image library was safe from Active Storage flaws.

The same releases also close a different Active Storage bug, GHSA-v924-7rp8-4mxh, which Rails scores 8.8 and rates high. Across both releases, Rails counts 21 security fixes.

What to ask your team

First, ask which Rails version each app runs. Ask whether config.active_storage.variant_processor is set to :mini_magick. Apps on unsupported series have no fixed version to move to.

Second, ask what the host's ImageMagick policy blocks. Rails suggests copying the rules from the policy file that ships with the fixed versions into the system-wide policy file, such as /etc/ImageMagick-7/policy.xml. The bare minimum is to deny three things: the MSL coder, every Ghostscript-backed coder, and the gs delegate. The advisory also lists patches for teams that cannot upgrade at once.

Third, plan for side effects. Apps on :mini_magick need mini_magick 5.1 or later. Older versions raise an error at boot. Apps that render PostScript or PDF through ImageMagick must allow the gs delegate again.

Some setups do not receive the shipped policy. These replace MiniMagick.cli_env after boot, clear the environment, or install their own shell. GraphicsMagick does not read ImageMagick policies at all.

Fourth, if uploads sit on the Disk service, Rails says to change secret_key_base and all other secrets the app can read. That covers the master key, everything in config/credentials.yml.enc, storage and database logins, and third-party tokens. Rails says not to keep an exposed secret as a fallback.

An upload form is a door. The policy behind it decides what a stranger can reach. Someone on your team should own that policy by name.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Rails project (rails/rails security team, Ruby on Rails).