Rails Fixes Critical File-Write Bug

A single uploaded file could be enough. According to the Rails project, a critical vulnerability in Active Storage lets an unauthenticated attacker write arbitrary files to an application's server if that application processes uploads through ImageMagick. The project published an advisory and released fixed versions, 8.1.4.1 and 8.0.5.2. The flaw carries a CVSS score of 9.8 out of 10 and is tracked as GHSA-f3w6-w445-fwh9. It does not yet have a CVE identifier.

Inside Active Storage's analyzer

The vulnerable component is Active Storage, the part of Rails that handles file uploads. When a file is attached, Active Storage's ImageMagick analyzer runs. Attaching the upload is enough to reach the flaw. The application does not have to make a variant — a transformed copy of the image — or generate a preview, and it does not have to call analyze.

ImageMagick picks a format handler, which it calls a coder, based on the file's content. Some coders act on other files named inside the image rather than on the image itself. Active Storage places no limits on which coders an upload can use, so the server's own ImageMagick policy was the only restriction in place.

According to the commit that fixed the flaw, an uploaded SVG file reached ImageMagick's MSL coder through that analyzer. MSL is a scripting coder that reads and writes files named by its script. That is the mechanism by which a crafted upload can turn into a file write on the server.

The read path matters too

Some applications store uploaded files using Active Storage's Disk service, which keeps them on the server's disk. In those applications, the Rails advisory says an attacker could also read any file the application 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. The advisory does not say whether the flaw has been exploited. Rails said one attack chain was reported to it, but it does "not assume it is the only one that exists."

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

Three conditions for exposure

Not every Rails application is affected. The advisory lays out three conditions, and all three must be true for an app to be exposed:

• It uses ImageMagick for Active Storage image processing — the setting config.active_storage.variant_processor = :mini_magick, which is 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.

A second flaw in the same releases

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. The two releases fix 21 security issues in total.

The July fix for a different critical Active Storage flaw, CVE-2026-66066, addressed 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.

What the shipped policy blocks

Rails strongly recommends upgrading as soon as possible. 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.

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.

Verifying the policy actually applies

Upgrading is only half the job. Rails advises confirming 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" }'.

The shipped policy 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.

The server's own ImageMagick policy still matters. 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.

Workarounds for apps that cannot upgrade yet

Rails offers a fallback for teams that cannot move to the fixed releases immediately. 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, the advisory says to 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. An exposed secret should not be kept as a fallback.

The detection gap

The advisory does not explain how to check whether an application has already been targeted. That leaves teams with remediation but without a documented way to confirm past compromise, a gap worth noting for anyone assembling an incident-response timeline around this bug.

Rails does not assume the reported attack chain is the only one. The MSL path is the one the fix commit documents, but the underlying issue is broader: Active Storage did not constrain which coders an upload could invoke, and the only guardrail was a policy most deployments never tuned.

Why this matters for Rails teams

For organizations running Rails applications that accept uploads from users outside the trust boundary, the timing here is tight. Rails 8.0 reaches the end of its security-fix window on November 7, 2026, which means an app still on that series has a narrow runway to move to 8.0.5.2 or later before the support clock runs out entirely. The set of applications exposed is also wider than it first appears: the :mini_magick default persisted for years of load_defaults settings, so long-lived applications that never revisited their configuration may match all three conditions without anyone having chosen ImageMagick deliberately.

The credential-rotation step deserves separate attention. If an app ran the Disk service and was reachable by untrusted uploads, the advisory's instruction to rotate secret_key_base and everything else the process could read suggests the project treats exposure of those secrets as a real possibility rather than a theoretical one. Teams that patch but skip rotation may be leaving the second half of the fix undone.

And because the shipped policy layers on top of the server's own ImageMagick configuration rather than replacing it, an upgrade alone does not guarantee the blocks are in effect. The verification command in the advisory exists precisely because that assumption can fail silently. This suggests that for teams running customized ImageMagick or GraphicsMagick setups, the practical work extends past the version bump into configuration review — and that the safest reading of the advisory is to treat the policy check as part of the remediation, not an optional follow-up.