Rails patches critical Active Storage ImageMagick upload flaw

Ruby on Rails has released versions 8.1.4.1 and 8.0.5.2 to fix a critical Active Storage vulnerability rated 9.8 out of 10 under CVSS. The issue, tracked as GHSA-f3w6-w445-fwh9, can allow an unauthenticated attacker to write arbitrary files to an application server when a crafted upload is processed through ImageMagick.

The flaw affects the Active Storage upload component rather than a feature that developers must explicitly invoke after upload. Rails said its ImageMagick analyzer runs when a file is attached, so attaching a malicious file can reach the vulnerable path. An application does not need to generate an image variant or preview, or call analyze, for processing to occur.

How crafted uploads reach ImageMagick

ImageMagick chooses a format handler, known as a coder, from a file's content. Some coders can operate on files named within the submitted image rather than on the image alone. Active Storage did not restrict the coders available to an upload, leaving the server's own ImageMagick policy as the effective safeguard.

Rails identified an uploaded SVG reaching ImageMagick's MSL coder through Active Storage analysis. MSL is a scripting coder that can read and write files named by its script. Rails said it had received one reported attack chain but did not assume that it was the only possible route. The advisory does not state whether the issue has been exploited.

Applications using Active Storage's Disk service face a further consequence. An attacker may be able to read files that the application process can read, which can include secret_key_base and credentials for other systems. Rails warned that access to those files can in turn enable remote code execution or lateral movement.

Which applications need attention

An application is affected when it uses ImageMagick for Active Storage processing, accepts uploads from untrusted users, and its ImageMagick policy does not already block the relevant coders. The affected configuration is config.active_storage.variant_processor = :mini_magick, which is the default for applications using load_defaults 6.1 or earlier. If the setting is absent, the default is MiniMagick before load_defaults 7.0 and vips from 7.0 onward.

Rails said Debian and Ubuntu policies do not block the involved coders. All Active Storage versions before 8.0.5.2 are affected, as are 8.1 releases before 8.1.4.1. Release lines older than 8.0 are unsupported and will not receive fixed releases.

The same updates also address GHSA-v924-7rp8-4mxh, a high-severity Active Storage issue with a CVSS score of 8.8. In that case, temporary filenames passed to ImageMagick and FFmpeg retained the uploaded extension, allowing a user who controls a filename and declared content type to influence decoder selection where file content does not identify the format.

Upgrade, verify policy, and rotate exposed secrets

Rails recommends upgrading promptly to 8.1.4.1 or 8.0.5.2. Applications using MiniMagick also require mini_magick 5.1 or later to avoid an error at boot. The releases include an ImageMagick security policy that blocks MSL, coders that read or delete other files, local and remote reference handling, Ghostscript-backed coders, the gs delegate, and @filename indirection.

Teams should confirm that the policy is loaded with bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'. It may 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, and an allow rule or wildcard in the system policy can override the shipped block.

If an immediate upgrade is not possible, Rails advises copying the shipped Active Storage policy rules into the ImageMagick system policy and, at minimum, blocking MSL, Ghostscript coders, and the gs delegate. Organisations using Disk service should rotate secret_key_base, the master key, credentials, database and storage credentials, and third-party tokens accessible to the application process. The practical priority is to patch, validate the effective policy rather than its presence alone, and treat readable application secrets as exposed where the vulnerable upload path may have been available.