A Critical Rails Bug Lets an Unauthenticated Upload Write Files on Your Server, and Debian and Ubuntu's Default ImageMagick Policy Does Not Stop It. No CVE, CVSS 9.8.
If you run a Rails app that accepts file uploads from the public, upgrade today: Rails 8.1.4.1 or 8.0.5.2. The Rails advisory published November 4 rates the flaw Critical, CVSS 9.8, with no authentication needed. If your app stores files on the Disk service, also rotate your secret_key_base and every secret the app process can read.
What the bug is
Active Storage is the part of Rails that handles file uploads. When an app uses ImageMagick through the mini_magick gem, ImageMagick picks a decoder, which it calls a coder, from the content of the uploaded file rather than from its name. Some coders do more than read an image: they act on other files named inside it. The Rails advisory says Active Storage placed no limits on any of those coders, so the only thing between an uploaded file and the server's disk was whatever policy ImageMagick itself was running under.
Worse, the analysis that triggers this runs when the file is attached. The advisory says attaching the upload is sufficient: no variant, preview or analyze call is needed. Per The Hacker News, the researcher who reported it showed an uploaded SVG reaching ImageMagick's MSL coder, which reads and writes files named in its script. Rails says one attack chain was reported and that it does not assume it is the only one.
The result, in the advisory's words, is that an unauthenticated attacker can write arbitrary files and, with the Disk service, read files the app process can read. Rails names secret_key_base and credentials for other systems as what that exposes, which can lead to remote code execution or lateral movement.
Are you exposed
All three of these have to be true:
- Your app uses ImageMagick for Active Storage. That means variant_processor is set to mini_magick, which is the default for apps on load_defaults 6.1 or earlier.
- The ImageMagick security policy on your server does not block the risky coders. The advisory notes that the default policies shipped by Debian and Ubuntu do not.
- Your app accepts uploads from people you do not trust.
Apps that use libvips instead are outside this advisory. A separate Active Storage flaw that did affect libvips, CVE-2026-66066, was fixed in July.
What to do
Upgrade to Rails 8.1.4.1 or 8.0.5.2, and use mini_magick 5.1 or later, because an older version raises an error at boot. The fixed releases ship an ImageMagick policy that blocks the MSL coder, coders that read or delete files, remote and local reference coders, the Ghostscript-backed coders, the gs delegate and the at-sign file indirection. Rails 8.0 only gets security fixes until November 7, so plan the move to 8.1 too. Anything older than 8.0 is unsupported and gets no fix.
Check that the policy actually loaded. Rails gives a one-line check using bin/rails runner and the MiniMagick policy listing. Three situations defeat the shipped policy: your app replaces MiniMagick.cli_env after boot, clears the environment with MiniMagick.cli_prefix, or installs its own MiniMagick::Shell. A rule in your server's own policy.xml that allows a coder, even by wildcard, also overrides the shipped block. And GraphicsMagick does not read ImageMagick policies at all. In those cases, put the rules in ImageMagick's system policy.
If you cannot upgrade yet, copy the rules from the file activestorage/lib/active_storage/image_magick/policy.xml in the Rails source into the system policy, for example the one under /etc/ImageMagick-7. At minimum, deny the MSL coder, the Ghostscript coders and the gs delegate. If you render PDF or PostScript through ImageMagick, you will need to allow the gs delegate again afterward.
If you use the Disk service, rotate secret_key_base and every other secret the process can read: the master key, credentials, storage and database credentials, and third-party tokens. Rails advises against keeping the exposed values as a fallback. The advisory gives no way to check whether an app was already targeted.
The second flaw
A separate advisory, GHSA-v924-7rp8-4mxh, is rated 8.8. Active Storage passed uploads to ImageMagick and FFmpeg under temporary names that kept the original extension. Because both tools can pick a decoder from the extension, someone who controls the filename and declared content type could influence which decoder ran. The same fixed releases cover it. Rails' workarounds for that one only change how FFmpeg is used and do not cover ImageMagick.
What we know and what we do not
Neither source says the flaw is being exploited, and neither says CISA has listed it. It has no CVE, so you will not find it by CVE id in a scanner yet; search for the GHSA identifiers. The researcher credited is RyotaK of GMO Flatt Security, reporting through HackerOne.
We hold nothing for the feed: this is a patch story with no published indicators, and there is nothing to block at the network edge until someone publishes exploit traffic. We will check our honeypots for upload-path probing once a public proof of concept appears.
Limits
We read the Rails advisory and The Hacker News summary of it. We did not reproduce the bug, and the SVG-to-MSL chain comes from The Hacker News, not from the advisory text. The advisory gives no ImageMagick version numbers.
Five percent of this is wrong somewhere. It always is. The numbers will move again before you finish reading.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.