Ruby on Rails flaw lets unauthenticated attackers write server files through crafted uploads
Ruby on Rails has fixed a critical Active Storage vulnerability that can let an unauthenticated attacker write arbitrary files to an application server through a crafted upload, the Rails project said in an advisory. The flaw affects Active Storage versions before 8.0.5.2 and 8.1 versions before 8.1.4.1. Rails rates it 9.8 out of 10 on the CVSS scale and tracks it as GHSA-f3w6-w445-fwh9; it does not yet have a CVE identifier.
An application is exposed only if it accepts uploads from untrusted users, uses ImageMagick for Active Storage image processing, and has an ImageMagick policy that does not block the relevant coders, according to Rails. A coder is ImageMagick's format handler. Debian and Ubuntu's shipped policies do not block the coders involved, Rails said.
The ImageMagick path is selected by config.active_storage.variant_processor = :mini_magick. Rails said that setting controls the library used to analyze uploads as well as the library used to create image variants. If the setting is absent, :mini_magick is the default before load_defaults 7.0, while :vips is the default from 7.0 onward.
The vulnerable code runs when Active Storage analyzes an attachment. The application does not need to create a variant, generate a preview or explicitly call analyze. Rails said an uploaded SVG reached ImageMagick's MSL coder through the analyzer. MSL is a scripting coder that reads and writes files named by its script.
Applications that use Active Storage's Disk service may also allow the attacker to read files the application can access. Rails said those files typically include secret_key_base and credentials for other systems. Reading them may allow remote code execution or movement into those systems.
Rails recommends upgrading to 8.1.4.1 or 8.0.5.2 as soon as possible. Applications using :mini_magick also need mini_magick 5.1 or later, or they will raise an error at boot. Release series older than 8.0 will not receive fixed versions, and Rails 8.0 receives security fixes only until November 7, 2026, under the project's maintenance policy.
The fixed releases ship an ImageMagick policy that blocks the MSL coder, coders that read or delete files other than the image, coders that fetch remote or local references or display them, Ghostscript-backed coders and the gs delegate, and @filename indirection, Rails said. The policy adds to the server's existing policy rather than replacing it. A server rule that allows a coder, including a wildcard such as pattern="*", can override the shipped block.
Rails said administrators can confirm that the application loads the new policy by running bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'. The shipped policy does not reach applications that replace MiniMagick.cli_env after boot, clear the environment with MiniMagick.cli_prefix or install a custom MiniMagick::Shell. GraphicsMagick does not read ImageMagick policies.
If an upgrade is not possible, Rails said administrators can copy the rules from activestorage/lib/active_storage/image_magick/policy.xml into ImageMagick's system policy, such as /etc/ImageMagick-7/policy.xml. At a minimum, the workaround should block the MSL coder, Ghostscript coders and the gs delegate. Rails said one attack chain had been reported to the project, but its advisory does not say whether the vulnerability has been exploited. For affected applications that store attachments with the Disk service, Rails advises changing secret_key_base and every other secret the application process could read.