Rails has fixed a critical flaw in Active Storage, the part of the framework that handles file uploads. If an app processes images with ImageMagick, an attacker with no account can upload a crafted file and write files on the server. Simply attaching the upload is enough.
Get the CyberExperts Daily Brief: the day's top security news in 5 minutes. Free.
Apps that keep uploads on the server’s own disk have a second problem. The same bug can read any file the app can read, including the secret key that signs sessions.
On a Rails app that uses ImageMagick, one crafted upload can write files on the server. Attaching it is enough.
The 5-Minute Cyber BriefDon’t Miss the Policy Changes That Affect Security Decisions
Get the key CISA actions, new regulations, guidance, and risk shifts in a quick daily brief.
By subscribing you agree to our Privacy Policy.
Free. Weekday mornings. 5 minutes or less.
A crafted image upload can write files on a Rails server
Rails released 8.1.4.1 and 8.0.5.2 on November 4 with fixes for 21 security issues. The worst is GHSA-f3w6-w445-fwh9, rated critical at 9.8. It has no CVE number yet.
According to the advisory and the fix commit, Active Storage’s image analyzer passed uploads to ImageMagick without limiting which format handlers it could use. An uploaded SVG could reach ImageMagick’s MSL scripting handler, which reads and writes files named in the script. RyotaK of GMO Flatt Security reported it through HackerOne.
A second Active Storage flaw in the same releases, GHSA-v924-7rp8-4mxh (high), let an attacker choose which decoder ImageMagick or FFmpeg used by picking the upload’s filename.
Rails apps that still hand uploads to ImageMagick
Three things must be true. The app uses :mini_magick for Active Storage, which is the default for apps still on load_defaults 6.1 or earlier. Its server’s ImageMagick policy does not block the handlers involved, and Rails says the policies Debian and Ubuntu ship do not. And it accepts uploads from people it does not trust, such as profile photos or support attachments.
Rails 8.0 gets security fixes only until November 7, two days from now. Series older than 8.0 get no fixed release at all.
Upgrade to 8.1.4.1 or 8.0.5.2 and confirm the new policy loads
- Find out which processor each app uses: check
config.active_storage.variant_processor, and if it is unset, the app’sload_defaultsversion. - Upgrade to Rails 8.1.4.1 or 8.0.5.2. Apps on
:mini_magickalso need the mini_magick gem at 5.1 or later or they will not boot. - Confirm the shipped ImageMagick policy is loaded:
bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'. A wildcard allow rule in the server’s ownpolicy.xmloverrides it. - Stuck on Rails 7.x or older? Copy the rules from
activestorage/lib/active_storage/image_magick/policy.xmlinto the system ImageMagick policy, and at minimum block MSL, the Ghostscript coders and thegsdelegate. - If the app stores attachments with the Disk service, rotate
secret_key_base, the master key and every credential inconfig/credentials.yml.enc.
Forward this
For whoever owns our Ruby on Rails apps: Rails fixed a critical upload bug that lets an attacker write files on the server if the app uses ImageMagick. Can we upgrade to 8.1.4.1 or 8.0.5.2 this week and, for apps that store uploads on local disk, rotate the app secrets?
Details
- GHSA-f3w6-w445-fwh9: arbitrary file write, and file read on the Disk service, through Active Storage image analysis with ImageMagick. Critical, CVSS 9.8. All Active Storage before 8.0.5.2, and 8.1 before 8.1.4.1. No CVE assigned as of November 4.
- GHSA-v924-7rp8-4mxh: file read and code execution in video previews, analysis and image processing through extension-based decoder choice. High.
- Not covered by the fix: apps using GraphicsMagick, which ignores ImageMagick policies, and apps that replace
MiniMagick.cli_envor install their ownMiniMagick::Shell. - Exploitation: the advisory does not report attacks.
Hunt / verify
- List SVG files that reached Active Storage through public forms, and open any that contain script or MSL markup instead of a picture.
- Look in the app and web root for files written by the app’s user that no deploy created, especially new
.rb,.erbor.htmlfiles. - Review logs for sign-ins with valid sessions from unknown IPs after any suspicious upload, since a stolen
secret_key_basecan forge sessions.
Source: Rails advisory GHSA-f3w6-w445-fwh9; Rails 8.0.5.2 and 8.1.4.1 release
Sources
- GitHub: Possible arbitrary file write and read in Active Storage image analysis (GHSA-f3w6-w445-fwh9)
- Ruby on Rails: Rails Versions 8.0.5.2 and 8.1.4.1 have been released (November 4, 2026)
- RubySec: GHSA-f3w6-w445-fwh9 (activestorage)
- The Hacker News: Critical Rails Flaw Lets Attackers Write Server Files via Crafted ImageMagick Uploads
Start your morning with the signal that matters.
Get the biggest cybersecurity developments, why they matter, and where to go deeper on CyberExperts.
By subscribing you agree to our Privacy Policy.
Free. Weekdays. Built for operators.