Critical Rails Active Storage ImageMagick Flaw (GHSA-f3w6-w445-fwh9): Prepare Now for Unauthenticated File Write via Uploads

Severity: Critical (CVSS 9.8 per the Rails advisory) · CVE: none assigned yet · CISA KEV: not listed

Executive Summary

On 4 November 2026 the Rails team published GHSA-f3w6-w445-fwh9, a flaw in Active Storage image analysis. According to the advisory, a Rails application that processes attachments with ImageMagick "may allow an unauthenticated attacker to write arbitrary files on the server". When attachments are stored with the Disk service, the attacker may also read any file the application process can read. Those files typically include secret_key_base and credentials for external systems, which Rails says "may in turn allow escalation to remote code execution or lateral movement to those systems." Fixed versions are activestorage 8.1.4.1 and 8.0.5.2. No CVE has been assigned yet. This post will be updated when one is.

Technical Information

ImageMagick picks a coder based on the content of the file it receives, and some coders act on files named inside the image rather than on the image itself. The advisory says Active Storage did not restrict any of ImageMagick's coders, and the ImageMagick analyzer runs when a file is attached. That means an attacker who can upload a crafted file may be able to invoke one of those coders. The advisory states: "Attaching the upload is sufficient; no variant, preview, or analyze call is required." Rails says one specific attack chain was reported to it, "but we do not assume it is the only one that exists."

The Rails advisory scores the issue Critical, 9.8 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), and classifies it as CWE-1188 (Initialization of a Resource with an Insecure Default). HackerOne researcher ryotak reported it.

The fixed releases ship their own ImageMagick security policy and prepend its directory to MAGICK_CONFIGURE_PATH through MiniMagick.cli_env. The policy denies the MSL scripting coder, coders that read or delete files other than the image, coders that fetch remote or local references or display to a screen, every Ghostscript-backed coder together with the gs delegate, and @filename indirection. It adds to the host's policy rather than replacing it, and it applies to every ImageMagick command MiniMagick runs.

Who is affected

The advisory says an application is affected only if it meets all of these conditions:

It uses ImageMagick for Active Storage image processing (config.active_storage.variant_processor = :mini_magick). This is the default for applications on load_defaults 6.1 or earlier.
It runs ImageMagick under a security policy that does not already deny the coders involved. The policies Debian and Ubuntu package do not deny them.
It accepts file uploads from untrusted users.

Affected Product Versions

Package (RubyGems)	Affected	Fixed
activestorage	>= 8.1, < 8.1.4.1	8.1.4.1
activestorage	< 8.0.5.2	8.0.5.2

The advisory lists no patched release below the 8.0 series. Rails also published patches for teams that can't upgrade right away: 468aa9a (8.1) and ea8c401 (8.0).

Workaround and Mitigation

Upgrade activestorage to 8.1.4.1 or 8.0.5.2.
mini_magick ≥ 5.1 is required when the variant processor is :mini_magick. With an older mini_magick, the patched application raises an exception during boot.
PDF/PostScript rendering: applications that render these through ImageMagick must re-allow the gs delegate and the coders they use in the host's policy.xml.
Custom MiniMagick setups: applications that replace MiniMagick.cli_env after boot, clear the environment with MiniMagick.cli_prefix, or install their own MiniMagick::Shell don't receive the shipped policy. They must put its rules in ImageMagick's system policy. GraphicsMagick does not read ImageMagick policies.
Disk service: rotate secrets. Change secret_key_base and every secret the application process can read, including the master key, everything in config/credentials.yml.enc, storage and database credentials, and third-party tokens. Rails says: "Do not retain an exposed secret as a fallback."
Workaround if you can't upgrade yet: copy the rules from activestorage/lib/active_storage/image_magick/policy.xml into ImageMagick's system policy (for example /etc/ImageMagick-7/policy.xml). At a minimum, deny the MSL coder, the Ghostscript coders, and the gs delegate:

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

Exploitation Status

The Rails advisory does not report exploitation in the wild, and GHSA-f3w6-w445-fwh9, which has no CVE yet, is not in CISA's Known Exploited Vulnerabilities Catalog (catalog version 2026.11.03, checked 4 November 2026). No public indicators have been published.

Indicators of Compromise

No indicators of compromise have been published by Rails or other primary sources at the time of writing. Because the advisory describes arbitrary file write and (with the Disk service) arbitrary file read, teams may want to review upload activity and unexpected file changes on Rails hosts that met all three conditions. Treat that review as hygiene, not as a published IOC set.

What to Do With Your Vendors Today

Any SaaS vendor that runs Rails with Active Storage and processes untrusted uploads with ImageMagick could meet all three conditions. For each vendor that accepts uploads from your users or staff, ask:

Do you use Rails Active Storage with ImageMagick (mini_magick) on untrusted uploads?
Have you upgraded activestorage to 8.1.4.1 or 8.0.5.2, or applied the ImageMagick policy workaround? When?
If you store attachments with the Disk service, have you rotated secret_key_base, the master key, and all credentials the app could read? When, and did you retire the old secrets entirely?

Our platform validates vendor claims against live attack-surface signal and chases findings to closure under your approval.

Need help working through SaaS suppliers running Rails and ImageMagick on user uploads exposed to GHSA-f3w6-w445-fwh9? Our team can help you prioritize them and track their answers. Talk to an expert