Rails' November 2026 Active Storage File Write and Read: GHSA-f3w6-w445-fwh9

#Overview

Rails released 8.1.4.1 and 8.0.5.2 on the evening of November 3, 2026 (US Central; November 4 UTC), fixing 21 security issues. The headline one is GHSA-f3w6-w445-fwh9 (opens in a new tab), "Possible arbitrary file write and read in Active Storage image analysis," which Rails rates Critical, CVSS 9.8. In an application that processes images with ImageMagick, an uploaded file can make ImageMagick write arbitrary files on the server, and, when attachments are stored with the Disk service, read any file the application can read. A sibling advisory rated High, GHSA-v924-7rp8-4mxh (opens in a new tab), covers file read and possible code execution through video previews. Neither has a CVE ID as of 10:45 AM CST on November 4. Rails' release announcement (opens in a new tab): "We strongly recommend upgrading as soon as possible."

Why it's urgent: the attack needs an upload and nothing else. Attaching the file is enough, with no variant, preview, or analyze call in the application, and an unauthenticated attacker can do it wherever the app accepts uploads from them, such as a profile-picture field open to anyone who signs up. Rails also says the one attack chain reported to it may not be the only one. The file read can reach secret_key_base and the credentials in config/credentials.yml.enc, which Rails says "may in turn allow escalation to remote code execution." And Rails 8.0's security support ends on November 7, four days after this release. See the timeline.

#Key facts

#Who is affected

A Rails version alone doesn't make an application vulnerable to GHSA-f3w6-w445-fwh9. Rails says an application is affected only if it meets all three of these:

• It processes Active Storage images with ImageMagick, which is config.active_storage.variant_processor = :mini_magick. That's "the default for applications on load_defaults 6.1 or earlier"; from load_defaults 7.0 the default is libvips, which this advisory doesn't involve.
• Its ImageMagick security policy doesn't already deny the coders involved. Rails: "The policies that Debian and Ubuntu package do not."
• It accepts file uploads from untrusted users.

We checked the packaged policies on November 4. None of them denies MSL, the scripting coder Rails' fix denies first, or the gs delegate:

The sibling advisory reaches further: it affects any app that accepts untrusted uploads and analyzes video or audio, which Active Storage does on attach by default, generates video previews, or processes images with ImageMagick. That includes apps on libvips.

#Builds outside the table

• Debian and Ubuntu package Rails themselves. Debian 12 ships rails 6.1.7.10, Debian 13 ships 7.2.2.2, Ubuntu 24.04 ships 6.1.7.3 in its universe repository, and Ubuntu 26.04 and 26.10 ship 7.2.3 and 7.2.3.2. All are below the fixed versions. Debian's tracker (opens in a new tab) lists all 21 advisories under temporary IDs, GHSA-f3w6-w445-fwh9 as TEMP-0000000-33AFA7, and marks every Debian release vulnerable as of 10:45 AM CST on November 4.
• The full ruby Docker images include ImageMagick. ruby:<version> builds on buildpack-deps, which installs Debian's imagemagick with Debian's policy; the -slim images don't. The Dockerfile that rails new generates installs libvips, not ImageMagick, so a generated app gets ImageMagick only if someone added it.
• GraphicsMagick doesn't read ImageMagick policies, so neither the fix's policy nor the workaround below covers an app that runs it.

#How the vulnerability works

When a file is attached, Active Storage analyzes it automatically, usually in a background job, to record metadata such as an image's dimensions. In an app whose processor is :mini_magick, the image analyzer calls ImageMagick.

ImageMagick handles each file format through a module it calls a coder, and it picks the coder from what the file contains. Rails explains that "some coders act on files named inside the image rather than on the image itself," and that Active Storage "constrained none of ImageMagick's coders." An attacker who can upload a crafted file can therefore reach a coder that writes files on the server. Rails ties the file read to the Disk service; the write doesn't depend on it.

The attacker needs no account if the app takes uploads from the public. What they get runs as the application's user: they can write wherever that user can write, and on the Disk service read what it can read, including secret_key_base, the master key, and everything config/credentials.yml.enc holds. secret_key_base is the key Rails signs and encrypts its cookies and messages with. ImageMagick's own security policy guide (opens in a new tab) describes how a policy restricts the coders and resources it may use.

#GHSA-v924-7rp8-4mxh: video previews and analysis

Active Storage hands uploads to ffprobe, ffmpeg, and ImageMagick under a temporary file name that keeps the uploaded file's extension, and those tools pick a decoder from the extension when the content doesn't identify its own format. So, per Rails, "an attacker who chooses the filename and declares the content type of an upload chooses which decoder processes it." An FFmpeg built with AviSynth support could then disclose files readable by the app through the preview image, or load a native library the attacker also uploaded, "possibly leading to remote code execution in the FFmpeg process." That attack needs an FFmpeg built with --enable-avisynth and the AviSynthPlus runtime. Per Rails, "Upstream FFmpeg and the common Linux distribution and Homebrew packages do not enable it; the GPL builds distributed for Windows and Linux from ffmpeg.org do." Rails adds that other decoders chosen by extension "may be reachable without AviSynth."

The fixed releases keep the extension only when it matches the blob's recorded content type, and otherwise name the temporary file with no extension.

#The fix

The fixed releases ship an ImageMagick security policy inside Active Storage and point every ImageMagick process that MiniMagick starts at it, through MAGICK_CONFIGURE_PATH. The policy has 33 deny rules: the MSL scripting coder, the coders that read or delete files other than the image (TEXT, EPHEMERAL), fetch references (URL, HTTP, HTTPS, FTP, FILE), read a pixel cache (MPC), or display to a screen; every Ghostscript coder and the gs delegate; and @filename indirection. ImageMagick applies every policy file on its search path, so this adds to the host's policy rather than replacing it, and it covers every ImageMagick command MiniMagick runs, not only Active Storage's.

The 8.0 commit, ea8c401 (opens in a new tab), adds the same policy and loader in 615 lines, most of them tests. We tested the shipped policy on November 4 by loading it through MAGICK_CONFIGURE_PATH with the ImageMagick that Debian 12, Debian 13, and Ubuntu 24.04 package: on all three, MSL was denied and ImageMagick refused a harmless PostScript test file.

#Which applications are exposed

What follows is our reading of the two advisories' requirements, not a confirmed exploit path for any one application.

The requirement that rules most apps in or out is the processor. Apps generated before Rails 7.0 and never moved to newer framework defaults run :mini_magick unless someone changed it, and they're also the apps likeliest to be on an unsupported Rails. Patch those first, and among them, the ones that store attachments on the Disk service, because the file read is what puts secrets at risk.

#How to check your systems

Run these in the application's repository, and on the hosts or images that run it. A fixed Rails applies its policy only to the ImageMagick processes MiniMagick starts, so the ImageMagick checks below show the system policy: what an unpatched app runs under, and where the workaround goes. We tested the commands with GNU grep 3.8 against two sample Rails apps, and the ImageMagick and FFmpeg checks in Debian 12, Debian 13, and Ubuntu 24.04 containers.

#Check the Rails and mini_magick versions

grep -E '^    (activestorage|mini_magick) \(' Gemfile.lock

This matches only the resolved versions, not the dependency lines beneath other gems. activestorage below 8.1.4.1 on the 8.1 line, or below 8.0.5.2 otherwise, is affected. If you use :mini_magick, mini_magick must read 5.1.0 or later before you upgrade Rails.

#Check the image processor and storage service

grep -rnE 'load_defaults|variant_processor' config/grep -rnE 'active_storage\.service *=' config/environments/grep -nE -B1 'service: *Disk' config/storage.yml

The first shows your framework defaults and any explicit processor. No variant_processor line and load_defaults 6.1 or lower means :mini_magick. The last two show whether the service your production environment uses is a Disk service; -B1 prints the service's name above its service: Disk line.

#Check ImageMagick's system policy

convert -version | head -1                                # ImageMagick 6magick -version | head -1                                 # ImageMagick 7convert -list policy | grep -B1 -E 'pattern: (MSL|gs)$'   # 6; use magick on 7

A denied coder prints rights: None above its pattern. No output means the system policy allows MSL and the gs delegate, which is what we found on all three distributions. Run it inside your production image, not on your laptop: docker run --rm --entrypoint sh your-image -c 'convert -list policy'.

#Check FFmpeg for AviSynth

ffmpeg -hide_banner -demuxers 2>/dev/null | grep -i avisynth

No output means no AviSynth demuxer. It printed nothing for Debian 13's FFmpeg 7.1.5. We didn't test a build with AviSynth enabled; per Rails, ffmpeg.org's GPL builds for Windows and Linux are the common ones that have it.

#How to fix

#Update Rails

Update to 8.1.4.1. 8.0.5.2 fixes 8.0, but 8.0's security support ends on November 7, so landing there means another upgrade next week. Rails' patches for 8.1 (opens in a new tab) and 8.0 (opens in a new tab) are there if you can't move gem versions at once. Restart every app server and background worker afterward; Active Storage analysis often runs in a job.

Four changes can break things on upgrade:

• mini_magick below 5.1 stops the app from booting when the processor is :mini_magick. Rails: "With an older mini_magick, such an application raises an exception during boot." mini_magick 5.1.0 shipped in January 2025, so bump it in the same change.
• PostScript and PDF through ImageMagick stop working. An app that renders them has to re-allow the gs delegate and the coders it uses in the host's policy.xml, because a host policy that allows a coder overrides the shipped deny.
• Some apps don't receive the shipped policy at all. Rails names three: one that replaces MiniMagick.cli_env after boot, clears the environment with MiniMagick.cli_prefix, or installs its own MiniMagick::Shell. They need the rules in the system policy, as in the workaround below.
• Two more from the same release. Direct uploads to Google Cloud Storage now send an x-goog-content-length-range header, so the bucket's CORS configuration must list it in responseHeader or browser uploads fail. And FFmpeg is now limited to common audio and video formats (config.active_storage.ffmpeg_allowed_formats), so files in other formats stop getting previews and metadata.

#Change secrets if you use the Disk service

Upgrading closes the hole but doesn't undo a read that already happened. If attachments are stored with the Disk service, Rails says to change secret_key_base and "every secret readable by the application process, including the master key and everything config/credentials.yml.enc holds, storage and database credentials, and third-party tokens," and adds: "Do not retain an exposed secret as a fallback." The video advisory asks the same of apps whose FFmpeg has AviSynth. Changing secret_key_base signs everyone out and invalidates signed and encrypted cookies, signed global IDs, and Active Storage URLs, so plan the rotation as a deploy of its own.

#If you can't patch immediately

Rails' workaround is to copy the shipped policy's rules into ImageMagick's system policy. At a minimum, deny the MSL coder, the Ghostscript coders, and the gs delegate. Add these lines just before </policymap> in /etc/ImageMagick-6/policy.xml (Debian 12, Ubuntu 24.04) or /etc/ImageMagick-7/policy.xml (Debian 13):

1<policy domain="coder" rights="none" pattern="MSL"/>2<policy domain="delegate" rights="none" pattern="gs"/>3<policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,EPS2,EPS3}"/>4<policy domain="coder" rights="none" pattern="{EPI,EPSF,EPSI,EPT,EPT2,EPT3}"/>5<policy domain="coder" rights="none" pattern="{PDF,AI,EPDF,PDFA,POCKETMOD,XPS,PCL}"/>

These are Rails' minimum rules, with its one long Ghostscript pattern split across three lines. We tested them on all three distributions on November 4: afterward, the policy check listed MSL and gs as denied and ImageMagick refused a harmless PostScript file, while ordinary PNG and JPEG conversion still worked where we checked it, on Debian 13 and Ubuntu 24.04. For the full set, copy every rule from the shipped policy.xml (opens in a new tab). In containers, make the change in the image, or the next deploy undoes it.

#End-of-life versions

Rails gives each minor release two years of security fixes from its first release. Only 8.1 and 8.0 are on its supported list (opens in a new tab), and Rails ships no fixed release for 7.2 or older. Its policy for unsupported series: "We may provide backports of the fixes and publish them to git, however there will be no new versions released." The advisory's patches are for 8.1 and 8.0 only.

For an app on 7.2 or older, the system-policy workaround above is the fix you can apply today; it works the same whatever the Rails version, because it changes ImageMagick, not Rails. Pair it with the FFmpeg workaround if the app handles video or audio, then plan the move to 8.1. Debian's and Ubuntu's packaged Rails are on these lines too.

#Timeline

#Other vulnerabilities fixed in this release

The release fixed 19 more issues. Titles and ratings are Rails'; "8.1 only" marks the four that don't reach 8.0. Each advisory links patches for both lines.

#Updates to this post

We'll revise this post and mark it updated when any of these change: CVE IDs or an NVD score for these advisories; Debian or Ubuntu tracking them or shipping fixed rails packages; a public proof of concept or a report of exploitation; a change to Rails' advisories; and Rails 8.0's end of security support on November 7.

#Get help

An outside scan can't read your Gemfile.lock, but it can see much of what surrounds it. Our free security audit fingerprints your stack, framework included, with versions where they show, checks every version it can read against its vendor's support window, and looks for files that should never be public, such as .env files and version-control folders, which hold the same kind of secrets this bug can read.

#Sources