---
title: "Rails Active Storage: Upload-to-File-Write via ImageMagick"
url: https://erroneo.us/security/briefs/rails-active-storage-imagemagick-file-write-ghsa-f3w6/
description: "Active Storage flaw (GHSA-f3w6-w445-fwh9, CVSS 9.8) lets crafted uploads write files via ImageMagick. Fixed in Rails 8.1.4.1/8.0.5.2. Check your processor."
type: security-brief
section: "Security Digest"
date_published: 2026-11-04
date_modified: 2026-11-05
publisher: erroneo.us
author: erroneo.us Security Desk
verdict: "Check exposure"
cves: []
severity: "critical"
exploited: "none-known"
kev: false
license: All rights reserved. Quote with attribution and a link.
---

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

**Verdict: Check exposure.** Only apps that run Active Storage through ImageMagick (:mini_magick) and accept untrusted uploads are exposed, but for them an unauthenticated upload can write files and, with the Disk service, read secret_key_base, so those apps should upgrade today.

- **Who must act:** Rails apps that accept uploads from untrusted users and use config.active_storage.variant_processor = :mini_magick (the default under load_defaults 6.1 or earlier) on hosts whose ImageMagick policy does not block MSL and Ghostscript coders, including stock Debian and Ubuntu.
- **Who can relax:** Apps on the :vips processor (the default from load_defaults 7.0), apps that do not use Active Storage, and apps that only accept uploads from trusted staff should still take the release but need not rush.
- **Affected:** activestorage before 8.0.5.2; activestorage 8.1.x before 8.1.4.1; All unsupported series before 8.0 (no fix will be released)
- **Fixed:** Rails / activestorage 8.1.4.1; Rails / activestorage 8.0.5.2 (8.0 security support ends November 7, 2026); Requires mini_magick 5.1 or later when using :mini_magick
- **CVEs:** none
- **CISA KEV:** no · **Exploitation:** No known exploitation

## 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

- 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](https://www.openwall.com/lists/oss-security/2026/11/04/2). The serious one is [GHSA-f3w6-w445-fwh9](https://github.com/rails/rails/security/advisories/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](https://github.com/rails/rails/commit/468aa9a93fc98f5476b6821770f4ccfcb7f7d328), 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](https://rubyonrails.org/maintenance) 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

1. [Rails — GHSA-f3w6-w445-fwh9: Possible arbitrary file write and read in Active Storage image analysis](https://github.com/rails/rails/security/advisories/GHSA-f3w6-w445-fwh9)
2. [oss-security — Rails security releases: 8.0.5.2 and 8.1.4.1](https://www.openwall.com/lists/oss-security/2026/11/04/2)
3. [Rails — fix commit for 8.1 (ImageMagick policy)](https://github.com/rails/rails/commit/468aa9a93fc98f5476b6821770f4ccfcb7f7d328)
4. [Rails — fix commit for 8.0](https://github.com/rails/rails/commit/ea8c40121ce53a3d0255cd4eb6d13bfe3bc01776)
5. [Rails — Maintenance policy](https://rubyonrails.org/maintenance)
6. [Rails Guides — Active Storage overview](https://guides.rubyonrails.org/active_storage_overview.html)
7. [The Hacker News — Critical Rails Flaw Lets Attackers Write Server Files via Crafted ImageMagick Uploads](https://thehackernews.com/2026/11/critical-rails-flaw-lets-attackers.html)

---
Source page: https://erroneo.us/security/briefs/rails-active-storage-imagemagick-file-write-ghsa-f3w6/ · Security Digest: https://erroneo.us/security/ · More: https://erroneo.us/llms.txt