A critical vulnerability has been discovered in **Ruby on Rails** that could allow unauthenticated attackers to write arbitrary files onto an application's server. The flaw, residing within the **Active Storage** component, is particularly dangerous if the application processes uploads using **ImageMagick**. ### The Nature of the Flaw **Active Storage** is the part of **Rails** responsible for handling file uploads. When applications use **Active Storage**'s Disk service to store uploaded files on the server, an attacker could exploit this vulnerability to not only write files but also read any file accessible by the application. According to the **Rails** project, such files typically include critical assets like the application's `secret_key_base` and credentials for other systems. Accessing these could pave the way for remote code execution or lateral movement within an organization's infrastructure. ### Technical Details and Impact Rated a severe 9.8 out of 10 on the CVSS scale, the flaw is tracked as GHSA-f3w6-w445-fwh9 and currently lacks a **CVE** identifier. The core issue lies in **ImageMagick**'s ability to select a format handler, or 'coder,' based on file content. Some of these coders can act on other files referenced within the 'image' itself, rather than just the image data. **Active Storage** previously imposed no restrictions on which coders an uploaded file could leverage, making the server's own **ImageMagick** policy the sole line of defense. The vulnerability is triggered when a file is attached, even without the need for variants, previews, or explicit `analyze` calls. An uploaded SVG file, for instance, could reach **ImageMagick**'s MSL coder through the analyzer. The MSL coder is a scripting mechanism that can read and write files specified by its script. While one attack chain has been reported, **Rails** warns that others likely exist. The advisory does not confirm if the flaw has been actively exploited in the wild. The vulnerability was responsibly reported via **HackerOne** by RyotaK, a researcher at **GMO Flatt Security**. ### Affected Applications An application is vulnerable if all three of the following conditions are met: * It uses **ImageMagick** for **Active Storage** image processing. This is typically configured via `config.active_storage.variant_processor = :mini_magick`, the default for apps on `load_defaults 6.1` or earlier. * Its **ImageMagick** security policy does not already block the involved coders. Notably, default policies shipped by **Debian** and **Ubuntu** do not block these. * It accepts file uploads from untrusted users. To verify the first condition, check the `config.active_storage.variant_processor` setting. If unset, the default is `:mini_magick` for versions before **Rails** 7.0 and `:vips` from 7.0 onwards. This setting dictates both variant generation and upload analysis. All **Active Storage** versions prior to 8.0.5.2 and **Rails** 8.1 versions before 8.1.4.1 are affected. Older release series (pre-8.0) are no longer supported and will not receive official fixes. It's worth noting that in July, **Rails** addressed a different critical **Active Storage** flaw (**CVE-2026-66066**) that impacted applications using **libvips** instead of **ImageMagick**. Applications using **ImageMagick** were immune to that specific threat but are now exposed to this new one. These same releases also patch a second **Active Storage** flaw, GHSA-v924-7rp8-4mxh, rated high with a CVSS score of 8.8. This vulnerability allowed attackers to choose the decoder for processing uploads by manipulating filenames and content types, as **Active Storage** passed files to **ImageMagick** and **FFmpeg** using temporary names that preserved the original extension. ### Mitigation and Recommendations **Rails** strongly advises upgrading immediately. The new releases address a total of 21 security issues. The patched versions ship with an updated **ImageMagick** security policy. When using **MiniMagick** (the **Ruby** gem for calling **ImageMagick**), this policy is applied to every **ImageMagick** command, blocking the MSL coder, coders that manipulate other files, those fetching remote or local resources, and **Ghostscript**-backed coders. **Key Actions:** * **Upgrade:** Update to **Rails** 8.1.4.1 or 8.0.5.2. Applications using `:mini_magick` also require **mini_magick** 5.1 or later to avoid boot errors. (Note: **Rails** 8.0 only receives security fixes until November 7, 2026). * **Verify Policy Loading:** Confirm the new policy is loaded by running `bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'`. Refer to the **Active Storage** guide for details. * **Check Policy Reach:** Ensure the shipped policy actually reaches your app. If `MiniMagick.cli_env` is replaced, the environment cleared with `MiniMagick.cli_prefix`, or a custom `MiniMagick::Shell` is installed, the rules must be manually added to **ImageMagick**'s system policy. * **GraphicsMagick Users:** Applications using **GraphicsMagick** receive no protection from the shipped policy, as **GraphicsMagick** does not read **ImageMagick** policies. * **Review Server Policy:** The shipped policy *adds* to, rather than replaces, your server's existing **ImageMagick** policy. Any rule in your server's `policy.xml` that allows a blocked coder (including wildcards like `pattern="*"`) will override the new policy. * **PDF/PostScript Rendering:** If your app renders PDF or PostScript files via **ImageMagick**, you may need to re-allow the `gs` delegate and related coders in your server's `policy.xml`. * **Temporary Workaround (If Upgrade Not Possible):** Copy the rules from `activestorage/lib/active_storage/image_magick/policy.xml` into **ImageMagick**'s system policy (e.g., `/etc/ImageMagick-7/policy.xml`). At a minimum, block the MSL coder, **Ghostscript** coders, and the `gs` delegate. Patches for **Rails** 8.1 and 8.0 are also available. * **Older Releases:** Apps on release series older than 8.0 should use the workaround or upgrade to 8.0 or later. * **Data Compromise:** If your app stores attachments with the Disk service, assume `secret_key_base` and all other secrets (master key, `config/credentials.yml.enc`, storage/database credentials, third-party tokens) that the app process can read have been compromised. Change them immediately and avoid using exposed secrets as fallbacks. Unfortunately, the advisory does not provide guidance on how to determine if an application has already been targeted by this specific vulnerability.