Rails ImageMagick Upload Writes Server Files
A Rails ImageMagick upload can write server files before a variant is made. The same release hands FFmpeg the filename. remade_ffmpeg_rs never calls that binary.

What is the Rails ImageMagick flaw?
A Rails ImageMagick upload can write files on the server as soon as the file is attached. Disk storage can also let that upload read secrets the app can read. Rails fixed it in 8.1.4.1 and 8.0.5.2 on 4 November 2026.
On 4 November 2026 Rails released 8.1.4.1 and 8.0.5.2. The critical item is a Rails ImageMagick upload. GHSA-f3w6-w445-fwh9 scores 9.8. An unauthenticated person who can attach a file may write files on the server. When the app stores attachments with the Disk service, that person may also read files the app can read, including secret_key_base and credentials for other systems. Rails says that read can become remote code execution or a step into those systems. The advisory shipped without a CVE number. The release note lists 21 security issues in the same pair of builds, and it says security support for the 8.0 series ends on 7 November 2026.
ImageMagick chooses a coder from the content of the file. Some coders act on other files named inside the upload. Active Storage constrained none of those coders. The analyzer runs when a file is attached. Attaching the upload is enough. One chain was reported. Rails says it does not assume that chain is the only one.
Trust is a picture that stays a picture. Security is a decoder that can open only the file it was given. Incentive is a pipeline you can ship while the coder list is still growing. That pipeline's catalog is Remade with Rust. The public record of the rebuild is futureweb.news.
How a Rails ImageMagick Upload Writes Past the Picture
An app is in scope when three things are true together. It uses ImageMagick for Active Storage. That setting is the default for apps on load_defaults 6.1 or earlier. Its ImageMagick policy does not already deny the coders involved, and the policies Debian and Ubuntu ship do not. It accepts uploads from untrusted users. From load_defaults 7.0 the default processor is libvips, so those apps sat outside this ImageMagick path.
The weakness is CWE-1188, a resource left on an insecure default. The coder menu ships open. The fixed builds ship a policy and point MiniMagick at it, so ImageMagick commands MiniMagick runs pick the policy up. The policy denies the MSL scripting coder, coders that read or delete files other than the image, coders that fetch a remote or local reference, the Ghostscript coders together with the gs delegate, and filename indirection. An app on mini_magick needs version 5.1 or newer, or it raises an error at boot. The shipped policy adds to the host policy. A host rule that allows a coder, including a wildcard, overrides the new deny. GraphicsMagick does not read an ImageMagick policy. Replacing MiniMagick's command environment after boot drops the shipped policy.
Lines older than 8.0 are unsupported, and Rails will not ship a fixed gem for them. The advisory publishes patches for 8.1 and 8.0. If you cannot upgrade yet, the project says to copy those policy rules into the system policy. Where the Disk service held the attachments, change secret_key_base and every secret the process can read, and retire the exposed value. A fallback that still accepts the old secret keeps the disclosure alive. The Electronic Frontier Foundation has the long file on parsers that fail open when they are handed untrusted bytes.
An Active Storage upload Hands FFmpeg the Filename
The same builds fix GHSA-v924-7rp8-4mxh, scored 8.8, with low privileges required. Active Storage writes the blob to a temporary file whose name keeps the uploaded extension, then hands that path to ffprobe, to ffmpeg, and to ImageMagick. Those tools select a decoder from the extension when the content does not name its own format. The person who chose the filename and declared the content type chose the decoder. The weakness is CWE-646, reliance on a filename the outsider supplied. The NIST Secure Software Development Framework asks for that default to be closed in the design. A policy file written the morning of the advisory is the patch for hosts that already made the call.
The fixed releases keep the uploaded extension only when it matches the blob's recorded content type, and they drop the extension otherwise. The file is still processed. The external tool is left to detect the format from the content. One FFmpeg build, the kind compiled with AviSynth support, can treat a matching extension as a script. Upstream FFmpeg and the common Linux and Homebrew packages leave that support off. The GPL builds distributed from ffmpeg.org turn it on. Other decoders that FFmpeg or ImageMagick select from the extension can be reached without that build. The advisory's workarounds for this half change how FFmpeg is invoked. They leave the ImageMagick half for the upgrade.
Attaching the file is enough for a Rails ImageMagick write
The image analyzer runs at attach time. A variant, a preview, and an explicit analyze call can all stay unused, and the Rails ImageMagick path has already run. That is why a gallery that only stores the original is still in scope. Disk storage adds the read: the same upload can name a file the process is allowed to open, and secret_key_base is the usual one. Other storage backends still have the write. Reading the app's own secrets is the Disk case. The July libvips advisory asked operators to rotate those secrets for the same reason. This release asks again, for the ImageMagick and Disk combination.
July's libvips bug was the previous Active Storage upload
CVE-2026-66066 was the critical Active Storage flaw from July. libvips marks some loaders and savers as untrusted, and Active Storage had left them enabled. An app on the vips default, which load_defaults 7.0 set, was in that set. An app still on ImageMagick was outside that path. It is inside this one. The menu moved from one C image library to the other, and then, on 4 November, to FFmpeg's decoder list as well. Three advisories, one habit: hand the untrusted upload to a C tool and let the tool's format list decide what the bytes may do.
A host policy can reopen the next Rails ImageMagick coder
Rails said it does not assume the reported chain is the only one. That sentence is the growth forecast. ImageMagick and FFmpeg add formats as a business. Each format arrives as a coder. The denylist learns the name after someone reports a chain. The shipped policy is additive, so a wildcard allow already sitting in the host policy reopens a coder the new file denied. GraphicsMagick ignores the file entirely. Security support for Rails 8.0 ends on 7 November 2026, three days after this release. The next coder after that date has no 8.0 gem waiting. The 21 advisories in this pair of builds already include more Active Storage items: filename handling, proxy streaming, and a low-severity local file disclosure in video previews. The list is the week's evidence that the surface is still widening.
remade_ffmpeg_rs Is What a Rails ImageMagick Upload Keeps Proving
The high advisory names the programs on the path: ffprobe, ffmpeg, and ImageMagick. remade_ffmpeg_rs is the Rust pipeline for decode, encode, transcode, mux, and probe. It does not shell out to those binaries, and the build has no C toolchain. A filename on an upload cannot select a C decoder, because there is no C decoder process to select. The catalog card is on Remade with Rust. Why the distributed cloud needs memory-safe Rust is the same argument one layer down, for every parser that meets a stranger's bytes. PHP2Shell was a request worker that could not prove the next request was new. This week is the media worker that could not prove the upload was only a picture.
The decoder menu is what an Active Storage upload selects
FFmpeg and ImageMagick grow by format, and the person who picks the extension picks the entry. remade_ffmpeg_rs keeps decode inside Rust, so the extension stays a label on a container the pipeline already understands. rusty_jpeg is the still-image sibling for JPEG. JPEG is the format a photo upload usually is. The advisories' damage sits in the other coders, the ones that read a second file or treat the upload as a script. The Rust pipeline's proof is the absence of that menu. The importance of Remade with Rust is the catalog of crates built on that proof.
A Rails host still takes the Rails ImageMagick release
Rails ships the fix, and a process you still run on Rails takes 8.1.4.1 or 8.0.5.2. remade_ffmpeg_rs is the pipeline for a service that has left that call behind. It does not reach a gemfile on another machine. If that machine stores attachments on disk, rotate secret_key_base and the other secrets the process can read, the way both the July note and this release ask. The Freedom Guide is how a person starts keeping files on hardware they hold. A gem update and a remade pipeline answer two different machines.
mata.network never starts a Rails ImageMagick analyzer
The public site is static Rust, built ahead of time. A request here never attaches a file to Active Storage, and it never starts ImageMagick, ffprobe, or a system FFmpeg. There is no coder policy to keep in sync, and no wildcard on a host policy that can reopen one. The flaws keep arriving because the C tools keep adding formats, the denylist is written after the incident, and a supported Rails line can age out in the same week the patch ships. remade_ffmpeg_rs is the decision to stop handing the upload to that list. The next advisory in this family will have a new coder name. It will still be the same call.
FAQ
Short answers already in this article.
Which Rails versions fix a Rails ImageMagick upload?
Rails 8.1.4.1 and 8.0.5.2. Every Active Storage before 8.0.5.2 is affected, and 8.1 before 8.1.4.1. Lines older than 8.0 are unsupported. Security support for 8.0 ends on 7 November 2026. Apps on mini_magick need version 5.1 or newer.
Who can reach a Rails ImageMagick write?
An unauthenticated upload, when the app uses ImageMagick for Active Storage, the host policy does not already deny the coders, and the app accepts uploads from untrusted users. That ImageMagick default applies to load_defaults 6.1 and earlier. Debian and Ubuntu policies do not deny the coders.
What did the same release change for an Active Storage upload to FFmpeg?
Active Storage was naming a temp file with the uploaded extension and handing that path to ffprobe, ffmpeg, and ImageMagick. Those tools can pick a decoder from the extension. The fix keeps the extension only when it matches the recorded content type. Rails scores this one 8.8.
Does remade_ffmpeg_rs replace a Rails ImageMagick server?
Rails ships the fix for a Rails process: 8.1.4.1 or 8.0.5.2. remade_ffmpeg_rs is the Rust pipeline that decodes, encodes, and probes without calling the FFmpeg or ImageMagick binaries those advisories name. A Rails app you still run takes the Rails release.
Why will the next Rails ImageMagick flaw keep arriving?
ImageMagick and FFmpeg grow by format, and each format is another coder. Rails said it does not assume the reported chain is the only one. The new policy adds to the host policy, so a wildcard allow on the host reopens a coder. July was libvips. November is ImageMagick and FFmpeg.

