Skip to main content
CybersecurityVulnerability Management

Rails Flaw Exposes Servers to File Write Attacks via ImageMagick Uploads

Server room with rows of equipment and a blurred laptop screen in the foreground.

"Rails rates the flaw 9.8 out of 10 on the CVSS scale." That stark number is the project's own assessment of a vulnerability in Active Storage that can let an unauthenticated attacker write arbitrary files to a server — and, in some configurations, read any file the application can read.

Active Storage, ImageMagick and the Disk service

The vulnerability affects Active Storage, the Rails component that handles file uploads. It is triggered when an application uses ImageMagick for image processing and stores uploads on the server's disk via Active Storage's Disk service. In that configuration, Rails says an attacker could not only write arbitrary files but also read files the app process can read — typically including secret_key_base and credentials used for other systems. Reading those secrets may, Rails warns, enable remote code execution or lateral movement into those systems.

How the attack reaches the server: the analyzer and ImageMagick coders

ImageMagick selects a format handler, called a coder, based on file content. Some coders act on files named inside the image rather than on the image itself. Active Storage imposes no limits on which coders an upload can use; until the patch, the only constraint was the server's ImageMagick policy. The ImageMagick analyzer that Active Storage runs when a file is attached is enough to reach the flaw — attaching the upload alone, Rails says, triggers the analyzer. It is not necessary for the app to make a variant, create a preview, or explicitly call analyze.

In the fix commit, Rails says an uploaded SVG file reached ImageMagick's MSL coder through that analyzer. MSL is a scripting coder that reads and writes files named by its script. One attack chain was reported to Rails; the advisory cautions that it does not assume that chain is the only one that exists and does not state whether the flaw has been exploited in the wild.

Which Rails apps are affected

  • An app is affected only if all three conditions are true: it uses ImageMagick for Active Storage image processing (config.active_storage.variant_processor = :mini_magick, the pre-7.0 default on apps with load_defaults 6.1 or earlier); its ImageMagick security policy does not already block the coders involved (Rails says the policies shipped by Debian and Ubuntu do not block them); and it accepts uploads from untrusted users.
  • Every Active Storage version before 8.0.5.2 is affected, as are 8.1 versions before 8.1.4.1. Release series older than 8.0 are no longer supported and will not receive patched releases.
  • Rails notes that apps using GraphicsMagick receive no protection from the shipped ImageMagick policy, because GraphicsMagick does not read ImageMagick policies.

Mitigations, fixes and practical steps

Rails fixed the flaw in versions 8.1.4.1 and 8.0.5.2 and published an ImageMagick security policy that blocks high-risk coders and behaviors. The policy blocks the MSL coder; coders that read or delete files other than the image; coders that fetch remote or local references or display them on a screen; every coder backed by Ghostscript, along with the gs delegate; and @filename indirection.

  • Rails' immediate recommendation: upgrade to Rails 8.1.4.1 or 8.0.5.2 as soon as possible. Apps that use :mini_magick also need mini_magick 5.1 or later, or they will raise an error at boot. Rails 8.0 receives security fixes only until November 7, 2026, under its maintenance policy.
  • Confirm that the app loads the new policy by running: bin/rails runner 'puts MiniMagick.identify {{ |i| i.list "policy" }}'.
  • Check the server's ImageMagick system policy: the shipped policy adds to system rules but does not replace them; a rule there that allows a coder — even a wildcard pattern="*" — will override the shipped block.
  • If the app replaces MiniMagick.cli_env after boot, clears the environment with MiniMagick.cli_prefix, or installs its own MiniMagick::Shell, the shipped policy will not reach the app; such setups must instead place the rules into ImageMagick's system policy (for example, /etc/ImageMagick-7/policy.xml).
  • If you cannot upgrade immediately, Rails advises copying activestorage/lib/active_storage/image_magick/policy.xml into ImageMagick's system policy and, at minimum, blocking the MSL coder, the Ghostscript coders, and the gs delegate. Rails also published patches for 8.1 and 8.0. Apps on release series older than 8.0 may use that workaround or upgrade to 8.0 or later.
  • Note: Rails fixed a separate, critical Active Storage flaw in July (CVE-2026-66066) that affected libvips users; that earlier fix did not affect apps using ImageMagick but the current issue does not overlap with those workarounds. The same releases also fix a second Active Storage flaw tracked as GHSA-v924-7rp8-4mxh (CVSS 8.8) involving temporary filenames and decoder selection; Rails' workarounds for that second flaw change FFmpeg usage and do not cover ImageMagick.
  • If an app stores attachments with the Disk service and secrets may have been exposed, Rails advises changing secret_key_base and every other secret the app process can read, including the master key, config/credentials.yml.enc contents, storage and database credentials, and third-party tokens; do not retain an exposed secret as a fallback.

What this means for technologists, procurement leaders, and end users

  • Technologists and security teams: prioritize identifying apps that use config.active_storage.variant_processor = :mini_magick (or earlier defaults), check the server ImageMagick policy and whether MiniMagick's environment has been altered after boot, and apply either the Rails releases or the policy-based workaround immediately.
  • Enterprises and procurement leaders: verify which applications store uploads with the Disk service and review maintenance timelines — Rails 8.0’s security support ends on November 7, 2026 — when planning patching and upgrade windows.
  • End users and the general public: organizations that accept file uploads from untrusted users are the locus of risk; users should expect faster patching and secret rotation where Disk storage is in use.

Rails tracks this flaw as GHSA-f3w6-w445-fwh9 and has not yet assigned a CVE identifier. The advisory and patches are the authoritative route to mitigation; Rails "strongly recommends upgrading as soon as possible," and it shipped policy and patches intended to reduce the attack surface for ImageMagick-driven analysis. The single concrete attack chain reported to Rails underlines the risk; whether others exist or whether exploitation occurred remains unreported.

Original Hacker News story