Rails Active Storage: Upload-to-File-Write via ImageMagick

What to do

1. Check your processor: bin/rails runner 'p Rails.application.config.active_storage.variant_processor'.
2. If it is :mini_magick and users can upload files, upgrade to Rails 8.1.4.1 or 8.0.5.2 and bundle update mini_magick to 5.1 or later.
3. If you cannot upgrade (or are on Rails 7.x or older), copy the shipped policy rules into /etc/ImageMagick-7/policy.xml (or ImageMagick-6) and at minimum deny the MSL coder, Ghostscript coders and the gs delegate.
4. Verify the policy is live: bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'.
5. If you use the Disk service and were exposed, rotate secret_key_base, the master key, credentials.yml.enc contents, database and storage credentials and third-party tokens.
6. Plan a move off Rails 8.0, whose security support ends November 7, 2026.

How to check if you are affected or compromised

• Search storage for uploaded blobs whose content is MSL or SVG with image or msl references despite an innocent filename or content type.
• Look for files written outside the storage root by the app user, for example new .rb, .erb, cron or SSH key files with recent modification times.
• Review ImageMagick processes started by the app for unexpected coders, and app logs for attachment analysis errors around unusual uploads.

What happened#

Rails released 8.1.4.1 and 8.0.5.2 on November 4, 2026 (UTC), fixing 21 security issues. The serious one is GHSA-f3w6-w445-fwh9, "Possible arbitrary file write and read in Active Storage image analysis," rated critical at CVSS 9.8. No CVE had been assigned as of November 5, 2026. RyotaK of GMO Flatt Security reported it through HackerOne.

The root cause is how ImageMagick works. It picks a "coder" based on what the file contains, not its name, and some coders read or write other files named inside the image. Active Storage never restricted which coders an upload could reach, so the server's ImageMagick policy was the only guard. Rails' analyzer runs as soon as a file is attached. No variant, preview or explicit analyze call is needed. According to the fix commit, the reported chain used an uploaded SVG to reach ImageMagick's MSL coder, a scripting format that can read and write arbitrary files. Rails says one chain was reported and warns that others may exist.

The result: an unauthenticated user who can upload may be able to write arbitrary files on the server. On apps using the Disk service, they may also read anything the app process can read, including secret_key_base and credentials for other systems. Either path can lead to code execution.

The same releases fix a related high-severity issue, GHSA-v924-7rp8-4mxh (CVSS 8.8). Active Storage handed uploads to ImageMagick and FFmpeg under temporary names that kept the original extension, so an attacker controlling the filename and declared content type could choose the decoder.

Who is affected#

All three of these must be true:

• The app uses ImageMagick via config.active_storage.variant_processor = :mini_magick. This is the default for apps on load_defaults 6.1 or earlier, which in practice means many older apps upgraded in place. From load_defaults 7.0 the default is :vips. The same setting chooses the library that analyzes uploads.
• The host's ImageMagick policy does not already deny the dangerous coders. Rails says the policies shipped by Debian and Ubuntu do not.
• The app accepts uploads from untrusted users: avatars, attachments, profile images.

Affected: activestorage before 8.0.5.2, and 8.1 before 8.1.4.1. Series older than 8.0 are out of support and will get no fix.

Do you really need to act?#

It depends on one config value, so check it now. If your app is on :vips, this critical issue does not apply. Take the release on your normal schedule anyway, for the other 20 fixes. If you are on :mini_magick and the public can upload, treat this as urgent. The attack needs no account beyond whatever lets someone upload, the trigger is just attaching the file, and arbitrary file write on a Rails host is usually one step from code execution. No exploitation has been reported as of November 5, 2026. Rails 8.0 users should note that 8.0's security support ends November 7, 2026, so this may be the last 8.0 fix.

What to do now#

1. Check the processor: bin/rails runner 'p Rails.application.config.active_storage.variant_processor'.
2. Upgrade: bundle update rails to 8.1.4.1 or 8.0.5.2. Apps on :mini_magick also need mini_magick 5.1 or later, or they will raise an error at boot. The fixed releases ship a policy at activestorage/lib/active_storage/image_magick/policy.xml that blocks MSL, coders that read or delete other files, remote and local references, Ghostscript coders, the gs delegate and @filename indirection.
3. Confirm the policy is active: bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'. It does not take effect if you replace MiniMagick.cli_env, use MiniMagick.cli_prefix or install a custom MiniMagick::Shell. It also loses to any server rule that allows a coder, including pattern="*". GraphicsMagick ignores it completely.
4. If you can't upgrade, or you're on Rails 7.x or older: copy those rules into the system policy (for example /etc/ImageMagick-7/policy.xml). At minimum, deny the MSL coder, the Ghostscript coders and the gs delegate. If you render PDFs or PostScript, re-allow only what you need.
5. If a :mini_magick app with Disk storage accepted public uploads, rotate secret_key_base, the master key, everything in credentials.yml.enc, and database, storage and third-party credentials. Don't keep the old values as fallbacks.

How to tell if you were hit#

Rails publishes no indicators and says nothing about detection. Reasonable checks: look in your storage service for blobs that are MSL, or SVG files referencing msl: or local paths, whatever their declared type (grep -rl -i 'msl:' storage/ for Disk). Look for files the app user wrote outside the storage directory, such as new Ruby or ERB files, cron entries or SSH keys (find / -user APPUSER -newer Gemfile.lock -type f 2>/dev/null). Also check logs for analyzer errors tied to odd uploads.

Timeline#

• Nov 4, 2026 — Rails 8.1.4.1 and 8.0.5.2 released with 21 fixes; GHSA-f3w6-w445-fwh9 published.
• Nov 5, 2026 — No CVE assigned and no exploitation reported.
• Nov 7, 2026 — Security support for Rails 8.0 ends.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. Rails — GHSA-f3w6-w445-fwh9: Possible arbitrary file write and read in Active Storage image analysis github.com
2. oss-security — Rails security releases: 8.0.5.2 and 8.1.4.1 openwall.com
3. Rails — fix commit for 8.1 (ImageMagick policy) github.com
4. Rails — fix commit for 8.0 github.com
5. Rails — Maintenance policy rubyonrails.org
6. Rails Guides — Active Storage overview guides.rubyonrails.org

Coverage and analysis

1. The Hacker News — Critical Rails Flaw Lets Attackers Write Server Files via Crafted ImageMagick Uploads thehackernews.com