The Ruby on Rails team has disclosed a critical flaw in Active Storage, the framework’s built-in file-upload system, that lets an attacker with no account and no special permissions make an application’s server write arbitrary files, and in some setups read them too, just by uploading a single crafted image. The bug carries a CVSS score of 9.8 and was published on November 4, 2026, though it does not yet have an assigned CVE identifier.

An Image Upload That Does More Than Upload an Image

The root of the problem lies in how ImageMagick, the image-processing library many Rails apps lean on, decides what to do with a file. Rather than trusting a file’s name or extension, ImageMagick inspects the file’s actual content to pick a “coder,” its term for the internal handler responsible for a given format. Some of those coders are capable of acting on other files referenced from inside the image data itself, a feature that can be useful for legitimate image composition but becomes dangerous the moment an attacker controls what gets uploaded.

Active Storage, Rails’ component for attaching files to database records, did not restrict which of these coders were allowed to run, and its built-in image analyzer kicks in automatically the moment a file is attached, with no need for the application to request a thumbnail, preview, or variant first. That combination means an attacker doesn’t need to find some obscure code path to trigger the bug; simply attaching the malicious upload is enough on its own.

What’s At Stake

The files most at risk from this kind of attack are exactly the ones a Rails application can least afford to lose: secret_key_base, the master key Rails uses to sign and encrypt sensitive data, along with credentials for other connected systems. Once an attacker gets hold of material like that, the Rails team notes, the path toward full remote code execution or further compromise of linked services becomes much shorter. Researchers have already reported one working attack chain built around the flaw, though the Rails team cautions that it shouldn’t be assumed to be the only one possible.

The vulnerability was reported by a researcher using the handle ryotak through HackerOne’s bug bounty platform.

Who Is Actually Affected

Not every Rails application is exposed, but the conditions that trigger the flaw are common enough to be worth checking carefully. An app is at risk if all of the following are true:

• It processes images through ImageMagick via the mini_magick variant processor, which is the default configuration for any app still running on load_defaults 6.1 or earlier.
• Its ImageMagick installation runs under a security policy that doesn’t already block the specific coders involved, which describes the policies shipped by default on both Debian and Ubuntu.
• It accepts file uploads from untrusted users, which covers the overwhelming majority of applications that let the public register accounts or submit content.

The affected versions are activestorage releases before 8.0.5.2 and before 8.1.4.1. Notably, this is a different flaw from CVE-2026-66066, an earlier Active Storage vulnerability tied to the libvips processor that Cyber Security News covered previously and which researchers later observed being exploited in real attacks. Teams that patched that earlier issue should not assume they are covered here, since this bug lives in a different image-processing path with its own separate fix.

How the Fix Works

Rather than rewriting how ImageMagick handles coders from scratch, the Rails team’s fix ships a dedicated ImageMagick security policy and wires it in through MiniMagick.cli_env, so that every ImageMagick process launched via MiniMagick automatically picks up the restrictive policy through the MAGICK_CONFIGURE_PATH environment variable. The new policy blocks the MSL scripting coder, any coder capable of reading or deleting other files, coders that fetch remote or local file references, every Ghostscript-backed coder, and a technique known as @filename indirection. Importantly, the policy adds these restrictions on top of whatever rules the host system already has in place, rather than replacing them outright.

What Rails Developers Should Do

• Upgrade activestorage to 8.0.5.2 or 8.1.4.1 immediately, depending on which release line your application tracks.
• If your app uses the mini_magick processor, also upgrade the mini_magick gem itself to version 5.1 or newer; older versions are incompatible with the fix.
• Audit any custom ImageMagick security policies to confirm they don’t inadvertently re-enable the coders this patch blocks.
• Treat any application accepting public image uploads as a priority for this patch, regardless of how the app otherwise handles authentication.

This marks the third notable image-processing security scare of the year across the Rails and PHP ecosystems, following similar issues in WordPress and Discourse that also traced back to ImageMagick or Ghostscript doing more with untrusted input than developers expected. The recurring lesson, as the Rails team itself points out, is that image-handling libraries are far more powerful, and far more dangerous when fed attacker-controlled input, than their simple “open a picture” reputation suggests.