Rails Active Storage Vulnerability: Critical ImageMagick Flaw Lets Uploads Write Server Files, Update to 8.1.4.1 or 8.0.5.2

Ruby on Rails has a critical flaw. Someone with no account can upload a crafted file and write files of their choosing onto your web server, as long as the app uses ImageMagick to process uploads. If your website, customer portal or internal tool is built on Rails and accepts uploads from the public, update to Rails 8.1.4.1 or 8.0.5.2. Both came out on Wednesday, November 4, 2026.

What happened

On November 4, 2026, the Rails team released Rails 8.1.4.1 and 8.0.5.2. These are security releases that fix 21 issues. The team says it "strongly recommend[s] upgrading as soon as possible." One of the 21 is rated Critical: advisory GHSA-f3w6-w445-fwh9, "Possible arbitrary file write and read in Active Storage image analysis."

Active Storage is the part of Rails that handles file uploads such as profile photos, documents and product images. When a file is attached, Rails runs an analyzer on it to read details like image size. According to the advisory, ImageMagick chooses how to read a file based on what is inside it, not on its name. Some of its file readers (it calls them "coders") act on other files named inside the image. Active Storage did not restrict those coders.

The advisory says: "Attaching the upload is sufficient; no variant, preview, or analyze call is required." So the upload alone triggers it. Your app does not need to resize or display the image.

What is confirmed and what is not

Confirmed by the Rails advisory and release post:

• An unauthenticated attacker may write arbitrary files on the server.
• If files are stored with the Disk service (on the server's own drive), the attacker may also read any file the app can read, including secret_key_base and credentials for other systems.
• The advisory says this could lead to remote code execution or lateral movement into other systems.
• Severity is Critical, CVSS 9.8. The issue was reported through HackerOne by the researcher ryotak.
• Affected: activestorage versions 8.1 up to but not including 8.1.4.1, and every version below 8.0.5.2.
• Fixed: 8.1.4.1 and 8.0.5.2.

Not known or not stated:

• The advisory lists no CVE number ("No known CVE").
• Neither the advisory nor the release post says the flaw has been used in real attacks. That does not mean it hasn't been. It means nobody has publicly confirmed it.
• The release post does not mention Rails 7.2 or 7.1 by name. The advisory's affected range covers every version below 8.0.5.2, and the Rails maintenance page lists only 8.1 and 8.0 as supported. No fixed 7.x release has been announced.

Is my Rails app affected?

The advisory says an app is affected only if all three of these are true:

1. It uses ImageMagick for Active Storage image processing. That means config.active_storage.variant_processor = :mini_magick. This is the default for apps on load_defaults 6.1 or earlier, so older apps that were upgraded over the years often still use it.
2. ImageMagick runs under a security policy that does not block the coders involved. The advisory says the policies Debian and Ubuntu ship do not block them, so a standard Linux server is likely exposed.
3. The app accepts uploads from untrusted users. Think public sign-up forms, support ticket attachments, job applications, or customer profile photos.

If you are not sure, ask your developer or hosting provider two questions: which activestorage version the app runs (it is listed in the app's Gemfile.lock), and which variant processor it is configured to use.

How to fix the Rails vulnerability this week

The Rails team also says that if you can't upgrade right away, each advisory links to patches you can apply yourself.

If you cannot update today

The advisory's workaround is to block the dangerous coders in ImageMagick's own system policy file:

• Copy the rules from the policy file that ships with the fixed Rails versions (activestorage/lib/active_storage/image_magick/policy.xml) into ImageMagick's system policy, for example /etc/ImageMagick-7/policy.xml.
• At minimum, deny the MSL coder, the Ghostscript coders (the PostScript, PDF, XPS and PCL formats) and the gs delegate.
• If your app uses GraphicsMagick, note that the advisory says GraphicsMagick does not read ImageMagick policies.
• Apps that customize how mini_magick runs commands may not pick up the shipped policy. The advisory says those apps must put the rules in ImageMagick's system policy.

This is a stopgap. The advisory's main advice is to upgrade.

Should you rotate secrets?

If attachments were stored with the Disk service, the advisory says to change secret_key_base and every secret the app process can read. That includes the master key, everything in config/credentials.yml.enc, storage and database credentials, and third-party tokens. It also says: "Do not retain an exposed secret as a fallback." Changing secret_key_base logs users out and invalidates signed cookies, so plan a time to do it.

Why this matters for a business website

A Rails app that takes uploads is usually doing something important: customer onboarding, quotes, claims, job applications or an online store. If an attacker can write files to that server, they may be able to plant code, change pages, or take the app's credentials and use them to reach your database, cloud storage or payment and email services. One upload form can open up the whole system behind it.

The timing matters too. Rails 8.0 security support ends November 7, 2026, three days after this release. Any app still on 8.0 after that date stops getting security fixes. Apps on 7.2 or older are already outside support. If the agency or freelancer who built your app has moved on, nobody may be watching for this.

The other Active Storage flaws in this release

The same release fixes a High-severity flaw, GHSA-v924-7rp8-4mxh (CVSS 8.8). It can allow file reads and possible code execution through video previews, video and audio analysis, and ImageMagick image processing. This one needs a logged-in user who can upload files. The worst version of the attack depends on an FFmpeg build with AviSynth support. Its workarounds are removing the video previewer and the video and audio analyzers. Other fixes in the release cover Strong Parameters, IP spoofing, cross-site scripting in view helpers, and several denial-of-service issues. Updating handles all of them at once.

Rails Active Storage vulnerability questions people are asking

Is there a CVE for the Rails ImageMagick flaw?

Not yet. The advisory is GHSA-f3w6-w445-fwh9 and says "No known CVE."

Does the attacker need an account?

No. The advisory describes an unauthenticated attacker, so any public upload form counts.

Is the Rails file upload flaw being exploited?

The advisory and release post do not say it is. There is no public confirmation either way.

Does Rails 7.2 get a fix?

No fixed 7.x release has been announced. The affected range covers all versions below 8.0.5.2, and only 8.0 and 8.1 are listed as supported. Apply the ImageMagick policy workaround and plan an upgrade.

Am I safe if I use libvips instead of ImageMagick?

The critical advisory lists ImageMagick (:mini_magick) as a requirement and does not mention libvips. Still update, because other flaws in this release affect video, audio and image handling.

What versions fix it?

Rails 8.1.4.1 and 8.0.5.2.

The bigger lesson

File uploads are one of the riskiest features a website can have, because they hand outside data straight to powerful tools running on your server. Defaults that were safe enough years ago can stay switched on through every upgrade. Someone needs to know which tools your app uses, which version it runs, and when its support ends.

Want help checking your apps and servers? See security hardening or request a quote.

Get security alerts like this by email, plus our free checklist, at /security-alerts.

Sources: Rails advisory GHSA-f3w6-w445-fwh9; Rails 8.0.5.2 and 8.1.4.1 release post; Rails advisory GHSA-v924-7rp8-4mxh; Rails maintenance policy.