# Rails' critical Active Storage bug lets one image upload write files on your server: who's exposed and what to do

> A CVSS 9.8 flaw in Rails' Active Storage, CVE-2026-122006, lets an unauthenticated upload reach ImageMagick's file-reading and file-writing coders. Rails 8.1.4.1 and 8.0.5.2 fix it along with 20 other security bugs, and Rails 8.0 stops getting security fixes on November 7.

Published Nov 6, 2026 by TechMeasured Staff · Security · Canonical: https://techmeasured.com/security/rails-active-storage-imagemagick-cve-2026-122006-upload-file-write-what-to-do

The **Ruby on Rails** team has fixed a critical flaw in **Active Storage**, the framework's built-in file upload component. An attacker who can upload a file to a Rails app that uses **ImageMagick** can write arbitrary files on the server, without logging in. The bug is tracked as **CVE-2026-122006** (GitHub advisory **GHSA-f3w6-w445-fwh9**) and scored **9.8 out of 10**. Fixed versions **Rails 8.1.4.1 and 8.0.5.2** shipped on **November 4**. The CVE record went public the same day.

Why it matters: in apps that store uploads with Active Storage's **Disk** service, the same flaw also lets the attacker read any file the app can read. According to the CVE record, that includes `secret_key_base`, the key Rails uses to sign and encrypt cookies and sessions. The Hacker News reports that Rails warns this could lead to remote code execution or lateral movement.

## What went wrong

ImageMagick decides how to decode a file by looking at its contents. It uses one of many "coders," and some of those coders can read or write other files. Active Storage never limited which coders an upload could reach, so only the server's own ImageMagick policy stood in the way. The Hacker News, summarizing the Rails advisory, says a crafted SVG could reach the **MSL** coder, which reads and writes files named in its script.

The trigger is simple. The ImageMagick analyzer runs as soon as a file is **attached**. Your app doesn't need to create a variant or a preview first.

Researcher **RyotaK of GMO Flatt Security** reported the flaw through HackerOne, according to The Hacker News.

## Are you affected?

Rails says all three of these must be true:

| Condition | How to tell |
|---|---|
| Active Storage uses ImageMagick (`variant_processor = :mini_magick`) | This is the default for apps on `load_defaults 6.1` or earlier. From 7.0 the default is `:vips` |
| Your ImageMagick policy doesn't block the dangerous coders | The stock Debian and Ubuntu policies **don't** block them, per the advisory |
| Untrusted users can upload files | Any public upload form counts |

Quick checks, from the DEV Community write-up of the advisory:

```bash
grep -rnE 'variant_processor|load_defaults' config
identify -list policy
```

The affected range is wide: every Active Storage version **before 8.0.5.2**, plus **8.1 before 8.1.4.1**, according to the CVE record. Rails 7.2 and older series are no longer supported, so they get no patch. Apps on those versions must use the workaround below or move to 8.0 or later.

This is a **different bug** from CVE-2026-66066, the critical Active Storage flaw fixed this summer. That one hit apps using **libvips**. ImageMagick apps weren't exposed to that attack, but they are exposed to this one.

## What to do

1. **Upgrade to Rails 8.1.4.1 or 8.0.5.2.** The fixed versions ship their own ImageMagick policy. It blocks MSL, coders that read or delete other files, remote and local references, Ghostscript coders and the `gs` delegate, and `@filename` indirection.
2. **Upgrade mini_magick to 5.1 or later** at the same time. Apps using `:mini_magick` will raise an error at boot without it.
3. **Confirm the policy is loaded:**
   ```bash
   bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'
   ```
4. **Can't upgrade yet?** Copy the rules from `activestorage/lib/active_storage/image_magick/policy.xml` into your system policy (for example `/etc/ImageMagick-7/policy.xml`). At minimum, block MSL, the Ghostscript coders and the `gs` delegate.
5. **If you use the Disk service, rotate secrets.** Rails advises rotating `secret_key_base`, the master key, the contents of `config/credentials.yml.enc`, and storage, database and third-party credentials. Don't keep the old secret as a fallback. Rotating `secret_key_base` logs users out and invalidates signed cookies and Active Storage URLs.

Gotchas, per the advisory as reported by The Hacker News:

- The shipped policy is skipped if your app replaces `MiniMagick.cli_env`, clears the environment with `MiniMagick.cli_prefix`, or installs its own `MiniMagick::Shell`. Those apps must put the rules in the system policy.
- **GraphicsMagick** users get no protection from the shipped policy.
- Server policies add to the shipped one. A rule that allows a coder, including `pattern="*"`, overrides the block.
- Apps that render **PDF or PostScript** through ImageMagick will find it blocked. They must re-allow `gs` and its coders deliberately.

## The other 20 fixes

The same releases fix **21 security issues**: 1 critical, 4 high, 13 medium and 3 low, according to the DEV Community and LinuxCompatible write-ups. The high-severity ones are:

- **GHSA-v924-7rp8-4mxh (8.8):** temporary files kept the uploaded file's extension, which lets attackers steer FFmpeg and ImageMagick's decoder choice. On FFmpeg builds with AviSynth support this could expose files or lead to RCE. Run `ffmpeg -version | grep -o enable-avisynth`; no output means AviSynth isn't enabled.
- **GHSA-wm3x-v3qw-4jh3 (7.5):** a Strong Parameters bypass via `Parameters#each_key`.
- **GHSA-8474-xrp6-wh69 (7.5):** a crash in `safe_constantize` that's reachable through Action Cable, which new apps mount at `/cable`.
- **GHSA-2gff-2mmg-m73p (7.4, 8.1 only):** IP spoofing via the `Forwarded` header.

## Is it being exploited?

The advisory doesn't say. CVE Brief's tracker listed no public exploit when we checked, and it wasn't among the CISA Known Exploited Vulnerabilities entries CVE Brief listed for November 5. Still, Rails says one attack chain was reported to it but does not "assume it is the only one that exists." After the summer libvips bug, public proof-of-concept code appeared quickly and Rails published technical details earlier than planned. Don't wait for that to happen again.

## Deadline: Rails 8.0

Rails 8.0's security support ends on **November 7, 2026**, so 8.0.5.2 is very likely its last security release. Rails 8.1 is supported until October 10, 2027, according to the DEV Community summary of Rails' maintenance policy. If you're on 8.0, patch now and plan the move to 8.1.


## Sources

1. [CVE Program — CVE-2026-122006 record (cvelistV5)](https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/122xxx/CVE-2026-122006.json)
2. [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)
3. [DEV Community — Patch your Rails: 21 security fixes in 8.0.5.2 and 8.1.4.1](https://dev.to/cseeman/patch-your-rails-21-security-fixes-in-8052-and-8141-1i7c)
4. [CVE Brief — CVE-2026-122006](https://cvebrief.com/cve/cve-2026-122006/)
5. [BleepingComputer — Rails patches critical Active Storage flaw with RCE potential (July libvips bug)](https://www.bleepingcomputer.com/news/security/rails-patches-critical-active-storage-flaw-with-rce-potential/amp/)
6. [LinuxCompatible — Rails 8.1.4.1 and 8.0.5.2 security release: 21 CVEs packed, 8.0 EOL in days](https://www.linuxcompatible.org/story/rails-8141-and-8052-security-release-21-cves-packed-80-eol-in-days)