VULNpocalypse
CriticalVulnerabilityPatch available

Critical Rails Active Storage flaw lets crafted ImageMagick uploads write server files

A critical Rails Active Storage flaw lets unauthenticated uploads write files through ImageMagick, fixed in activestorage 8.1.4.1 and 8.0.5.2.

Published
Fixed in
activestorage 8.1.4.1 or 8.0.5.2, plus mini_magick 5.1 or later for apps using :mini_magick
Exploitation
Not confirmed. The Rails advisory does not say whether this flaw has been exploited.

What happened

On Nov 4, 2026 the Rails project published a critical advisory, GHSA-f3w6-w445-fwh9, for Active Storage. It is rated 9.8 on CVSS and has no CVE ID (“No known CVE”) (Rails GitHub advisory). The Hacker News and Cyber Security News both report the same facts (The Hacker News, Cyber Security News).

An app that processes attachments with ImageMagick may let an unauthenticated attacker write arbitrary files on the server. When attachments are stored with the Disk service, the attacker may also read any file the app process can read. Those files typically include secret_key_base and credentials for external systems, which may lead to remote code execution or lateral movement (Rails GitHub advisory).

The root cause is as follows, per the Rails advisory:

  • ImageMagick picks a coder (a format handler) from the content of a file, and some coders act on other files named inside the image.
  • Active Storage constrained none of ImageMagick’s coders.
  • The ImageMagick analyzer runs when a file is attached, so attaching the upload is enough. No variant, preview or analyze call is needed.

The Hacker News, citing the fixing commit, says an uploaded SVG reached ImageMagick’s MSL scripting coder through the analyzer (The Hacker News). Rails says one attack chain was reported but it does not assume it is the only one (Rails GitHub advisory). The advisory does not say whether the flaw has been exploited, so exploitation is not confirmed. The flaw was reported through HackerOne by the researcher ryotak (Rails GitHub advisory).

The same releases fix a second Active Storage flaw, GHSA-v924-7rp8-4mxh, rated High (CVSS 8.8). Active Storage wrote uploads to temporary files that kept the uploaded extension and passed them to ffprobe, ffmpeg and ImageMagick. These tools can choose a decoder from the extension, so an attacker who controls the filename and declared content type can choose the decoder. The AviSynth attack path needs an FFmpeg built with --enable-avisynth and the AviSynthPlus runtime. That second flaw was reported by pirikara (Rails GitHub advisory GHSA-v924-7rp8-4mxh). The two releases fix 21 security issues in total (The Hacker News).

This is separate from CVE-2026-66066, a July Active Storage flaw that affected apps using libvips. Apps on ImageMagick were not exposed to that attack path but can be exposed to this one (The Hacker News). Teams that patched in the summer should not assume they are safe now (Cyber Security News).

Am I affected?

Per the Rails advisory, an app is affected only if all three of these are true (Rails GitHub advisory):

  1. It uses ImageMagick for Active Storage image processing, meaning config.active_storage.variant_processor = :mini_magick. This is the default for apps on load_defaults 6.1 or earlier.
  2. It runs ImageMagick under a security policy that does not already deny the coders involved. The policies packaged by Debian and Ubuntu do not.
  3. It accepts file uploads from untrusted users.

Affected versions are activestorage before 8.0.5.2, and 8.1 releases before 8.1.4.1. If the variant processor is not set, the default depends on load_defaults. It is :mini_magick before 7.0 and :vips from 7.0 on, and the setting also decides which library analyzes uploads (The Hacker News). Release series older than 8.0 are unsupported and Rails will not release fixed versions for them (The Hacker News).

Apps using GraphicsMagick get no protection from the shipped policy, because GraphicsMagick does not read ImageMagick policies (Rails GitHub advisory). The advisory does not explain how to check whether an app has already been targeted (The Hacker News).

What to do now

  1. Check config.active_storage.variant_processor and your load_defaults to see whether the app uses :mini_magick, and whether it accepts untrusted uploads.
  2. Upgrade activestorage to 8.1.4.1 or 8.0.5.2. Apps on :mini_magick also need mini_magick 5.1 or later, or they raise an exception at boot (Rails GitHub advisory). Rails 8.0 gets security fixes only until November 7, 2026 (The Hacker News).
  3. Confirm the new policy is loaded by running bin/rails runner ‘puts MiniMagick.identify { |i| i.list “policy” }’ (The Hacker News).
  4. Check whether the shipped policy reaches your app. It does not reach an app that replaces MiniMagick.cli_env after boot, clears the environment with MiniMagick.cli_prefix, or installs its own MiniMagick::Shell. Such an app must carry the rules in ImageMagick’s system policy (Rails GitHub advisory).
  5. Review the server’s own ImageMagick policy. The shipped policy adds to it rather than replacing it, and a host rule that allows a coder, including a wildcard such as pattern=”*”, overrides the shipped block on that coder (The Hacker News).
  6. If the app renders PostScript or PDF through ImageMagick, re-allow the gs delegate and the coders it uses in the host’s policy.xml (Rails GitHub advisory).
  7. If you cannot upgrade yet, copy the rules from activestorage/lib/active_storage/image_magick/policy.xml into the system policy, for example /etc/ImageMagick-7/policy.xml. At a minimum, deny the MSL coder, the Ghostscript coders and the gs delegate. Rails also published patches (8.1: commit 468aa9a, 8.0: commit ea8c401) (Rails GitHub advisory). Apps on series older than 8.0 can use this workaround or move to 8.0 or later (The Hacker News).
  8. If attachments use the Disk service, 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. Do not keep an exposed secret as a fallback (Rails GitHub advisory). Changing secret_key_base expires active sessions and invalidates signed and encrypted cookies, signed global IDs and Active Storage URLs (Rails GitHub advisory GHSA-v924-7rp8-4mxh).
  9. For the second flaw, if you cannot upgrade, remove VideoPreviewer from config.active_storage.previewers and VideoAnalyzer and AudioAnalyzer from config.active_storage.analyzers. These workarounds only change how FFmpeg is used and none of them covers ImageMagick (Rails GitHub advisory GHSA-v924-7rp8-4mxh).
  10. Review logs for odd uploads and make sure no app runs with extra file permissions (Cyber Security News).

Sources