Rails' critical Active Storage bug lets one image upload write files on your server: who's exposed and 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:

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

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:

   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.