Rails Active Storage

A single file upload is enough. No authentication, no variant generation, no preview call, no explicit analyze invocation. Just attach the file and the flaw is already in play.

The Rails project disclosed this one in an advisory and fixed it in versions 8.1.4.1 and 8.0.5.2. It carries a 9.8 CVSS score and is tracked as GHSA-f3w6-w445-fwh9. No CVE has been assigned yet.

Where the Flaw Lives

The problem is in Active Storage, the part of Rails that handles file uploads. Specifically, it lives in how Active Storage's ImageMagick analyzer interacts with the coders ImageMagick selects.

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, 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 thing standing in the way.

The analyzer runs when a file is attached. That is the entire trigger condition. The application does not need to make a variant, generate a preview, or call analyze.

According to the commit that fixed the flaw, an uploaded SVG reached ImageMagick's MSL coder through that analyzer. MSL is a scripting coder. It 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 in the wild.

The report came through HackerOne from RyotaK, a researcher at GMO Flatt Security.

The Disk Service Problem

If your app uses Active Storage's Disk service to store uploads, the impact gets significantly worse. The Disk service writes files to the server's disk, and in that configuration an attacker can also read any file the app itself can read.

Rails is explicit about what those files typically contain. The app's secret_key_base. Credentials for other systems. Reading them may in turn enable remote code execution or lateral movement into those connected systems.

That escalates this from a file-write bug into a full application compromise, depending on what else the app can reach.

Which Apps Are Actually Affected

An app is in scope only if all three of these conditions are true.

The first condition deserves a closer look. If variant_processor is not set explicitly, the default depends on load_defaults. It is :mini_magick before Rails 7.0 and :vips from 7.0 onward.

The same setting decides which library analyzes uploads, not just which one makes variants. That is a detail people miss.

Rails notes that the policies shipped by Debian and Ubuntu do not block the coders involved. So the distro defaults do not protect you.

Version Coverage

Every Active Storage version before 8.0.5.2 is affected. So are 8.1 versions before 8.1.4.1.

Release series older than 8.0 are no longer supported. Rails will not publish fixed versions for them.

One timing detail is worth flagging. Rails 8.0 receives security fixes only until November 7, 2026, under its maintenance policy. That is days away.

The Second Flaw in the Same Release

The same releases fix a second Active Storage vulnerability tracked as GHSA-v924-7rp8-4mxh. Rails rates it 8.8, which is high.

Active Storage was passing uploads to ImageMagick and FFmpeg under temporary filenames that preserved the uploaded file's extension. Those tools can select a decoder based on the extension when the file's content does not clearly show its format.

So an attacker who controls both the filename and the declared content type can pick the decoder that processes their upload.

In July, Rails fixed a different critical Active Storage flaw, CVE-2026-66066, which affected apps using libvips. Apps on ImageMagick were not exposed to that attack path. They are exposed to this one.

The two releases together fix 21 security issues.

How to Patch

Rails strongly recommends upgrading as soon as possible.

• Upgrade to 8.1.4.1 or 8.0.5.2.
• Update mini_magick to 5.1 or later. If your app uses :mini_magick and you skip this, the app raises an error at boot.
• Verify the new policy is loaded. The fixed versions ship an ImageMagick security policy, and MiniMagick is the gem Active Storage uses to call ImageMagick. Run bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }' to confirm it is active.
• Check whether the shipped policy actually reaches your app. 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. Those apps must put the rules in ImageMagick's system policy directly.
• Note that GraphicsMagick gets nothing. The shipped policy does not protect apps using GraphicsMagick, because GraphicsMagick does not read ImageMagick policies.

What the Shipped Policy Blocks

The policy bundled with the fix blocks the following:

• The MSL coder
• Coders that read or delete files other than the image
• Coders that fetch remote or local references, or display them on screen
• Every coder backed by Ghostscript, along with the gs delegate
• @filename indirection

One caveat matters here. The shipped policy adds to your server's existing policy rather than replacing it. A rule in the server policy that allows a coder, including a wildcard such as pattern="*", overrides the shipped block on that coder.

If your app renders PDF or PostScript through ImageMagick, you will need to re-allow the gs delegate and the coders it uses in policy.xml.

If You Cannot Upgrade Yet

Copy the rules from the shipped policy file at activestorage/lib/active_storage/image_magick/policy.xml into your system policy, typically /etc/ImageMagick-7/policy.xml.

At minimum, block the MSL coder, the Ghostscript coders, and the gs delegate. Rails also published the fix as patches against 8.1 and 8.0 for teams that cannot move to the release builds immediately.

Apps on release series older than 8.0 can use that workaround or upgrade to 8.0 or later.

Note that Rails' workarounds for the second flaw only change how FFmpeg is used. None of them covers ImageMagick.

If You Use the Disk Service, Rotate Everything

This step is not optional if your 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 credentials, database credentials, and third-party tokens.

Do not keep the exposed secret as a fallback. Rotate it properly.

The advisory does not explain how to determine whether an app has already been targeted, so treat the rotation as mandatory rather than contingent on evidence.

FAQ

What is GHSA-f3w6-w445-fwh9?

A critical (9.8) vulnerability in Rails Active Storage. An unauthenticated attacker can write arbitrary files on the server by uploading a crafted file that reaches an unsafe ImageMagick coder.

Does my app need to process variants to be vulnerable?

No. The analyzer runs when a file is attached. You do not need to call analyze, generate a variant, or create a preview. Attaching the upload is enough.

Which Rails versions are affected?

Every Active Storage version before 8.0.5.2, and 8.1 versions before 8.1.4.1. Release series older than 8.0 are no longer supported and will not receive fixes.

How do I know if my app uses ImageMagick?

Check config.active_storage.variant_processor. If it is not set, the default is :mini_magick for apps on load_defaults 6.1 or earlier, and :vips from 7.0 onward.

Does the Debian or Ubuntu ImageMagick policy protect me?

No. Rails says the policies shipped by those distributions do not block the coders involved.

Why do I need to rotate secrets if I use the Disk service?

Because the Disk service stores files on the server's disk, and the flaw also allows reading any file the app can read. That includes secret_key_base, credentials, and database secrets.

Do I need to update mini_magick separately?

Yes, if your app uses :mini_magick. You need mini_magick 5.1 or later, or the app raises an error at boot.

Does GraphicsMagick get the same protection?

No. GraphicsMagick does not read ImageMagick policies, so the shipped policy provides no protection for apps using it.

Source : The Hacker News