A critical vulnerability in Ruby on Rails could allow an unauthenticated attacker to write arbitrary files to a server by uploading a crafted file, if the application processes uploads with ImageMagick. Rails disclosed the issue in a security advisory and released fixes in versions 8.1.4.1 and 8.0.5.2.
The flaw affects Active Storage, Rails’ file-upload component. Apps are at risk when they use ImageMagick to process uploads, accept files from untrusted users, and have an ImageMagick security policy that does not block the relevant coders. Rails notes that Debian and Ubuntu’s shipped policies do not block them.
The risk can extend beyond file writing. Apps using Active Storage’s Disk service store uploaded files on the server, and an attacker may also be able to read files accessible to the application. These can include Rails’ secret_key_base and credentials for other systems, which could enable further compromise, including remote code execution or movement into connected systems.
Rails rates the vulnerability 9.8 out of 10 on the CVSS scale. It is tracked as GHSA-f3w6-w445-fwh9 and has no CVE identifier. The issue was reported through HackerOne by RyotaK, a researcher at GMO Flatt Security. Rails said it received a report of one attack chain, while cautioning that other methods may exist; the advisory does not state whether the flaw has been exploited.
The vulnerable path is reached when Active Storage analyzes an attached upload. A variant or preview does not need to be generated, and the app does not need to call the analyze method. According to the fix commit, an uploaded SVG could reach ImageMagick’s MSL coder, which can read and write files named in its script. Active Storage did not restrict which ImageMagick coders could process an upload, leaving the server’s ImageMagick policy as the only control.
All Active Storage versions before 8.0.5.2 are affected, as are 8.1 versions before 8.1.4.1. Rails says release series earlier than 8.0 are unsupported and will not receive fixed releases. The relevant configuration is config.active_storage.variant_processor: :mini_magick uses ImageMagick, while the default depends on the app’s load_defaults setting. That setting also determines which library analyzes uploads.
The same releases address a separate Active Storage vulnerability, GHSA-v924-7rp8-4mxh, rated 8.8 on the CVSS scale. In that issue, uploads were passed to ImageMagick and FFmpeg under temporary filenames that retained their extensions, potentially letting an attacker influence which decoder handled a file. Rails says the two releases fix 21 security issues in total.
Rails strongly recommends upgrading. Apps using :mini_magick also need mini_magick 5.1 or later, or they may encounter an error during startup. The releases include an ImageMagick policy that blocks MSL, certain coders that can access other files or references, Ghostscript-backed coders and the gs delegate, and @filename indirection.
Administrators should confirm that the app loads the new policy and check whether custom MiniMagick configuration prevents it from taking effect. The policy supplements, rather than replaces, the server’s ImageMagick policy, so an existing rule allowing a coder can override the new block. The included policy does not protect apps using GraphicsMagick.
If an upgrade is not possible, Rails recommends applying the shipped policy rules to ImageMagick’s system policy, at minimum blocking MSL, Ghostscript coders, and the gs delegate. For apps using the Disk service, Rails also advises changing secret_key_base and every other secret readable by the application, including credentials, storage and database passwords, and third-party tokens. The advisory does not provide a method to determine whether an app has already been targeted.
Sources: The Hacker News.