Critical Rails flaw allows file writes via ImageMagick uploads

A severe security vulnerability in Ruby on Rails allows unauthenticated attackers to write arbitrary files to a server by uploading specially crafted images. The Rails project released fixes in versions 8.1.4.1 and 8.0.5.2 on November 4, 2026, addressing a flaw in the Active Storage component when used with ImageMagick.

What happened

The vulnerability resides in how Active Storage handles file uploads when configured to use ImageMagick for image processing. When an application accepts a file upload, Active Storage runs an analyzer to determine the file type. This process triggers ImageMagick to inspect the content, which selects a format handler, known as a coder, based on what it finds inside the file. Some of these coders are designed to act on external files referenced within the image data rather than just the image itself.

In this specific case, an attacker can upload an SVG file that invokes the MSL coder, a scripting format capable of reading and writing files specified in its script. Because Active Storage did not restrict which coders could be used during analysis, the server’s default ImageMagick policy became the only line of defense. On many systems, including those running Debian or Ubuntu, the default policy does not block these dangerous coders. Consequently, simply attaching a malicious file is enough to exploit the flaw, without needing to generate previews or transform the image.

If the application stores files using the Disk service, the attacker can also read any file the application has permission to access. This typically includes sensitive credentials such as the secret_key_base, database passwords, and third-party API tokens. Access to these secrets can lead to remote code execution or lateral movement into other connected systems. The Rails team rated this vulnerability 9.8 out of 10 on the CVSS scale, indicating near-maximum severity.

Key details

• The vulnerability is tracked as GHSA-f3w6-w445-fwh9 and affects Rails versions prior to 8.0.5.2 and 8.1.4.1.
• It requires the application to use config.active_storage.variant_processor = :mini_magick, which is the default for older Rails configurations.
• The attack vector involves uploading a crafted file, such as an SVG, that triggers ImageMagick’s MSL coder during the attachment analysis phase.
• Apps using the Disk service for storage are at higher risk because attackers can read sensitive configuration files and secrets from the server.
• The fix introduces a strict ImageMagick security policy that blocks dangerous coders like MSL, Ghostscript, and those allowing file indirection.
• A second high-severity flaw, GHSA-v924-7rp8-4mxh, was also fixed in these releases, relating to how file extensions influence decoder selection in FFmpeg and ImageMagick.

Background

Active Storage is the standard framework in Rails for managing file attachments. It delegates image processing tasks to external libraries, commonly ImageMagick or libvips. ImageMagick is a powerful tool that supports hundreds of image formats, each handled by a specific coder. While this flexibility is useful for developers, it introduces security risks if certain coders are allowed to execute scripts or access the filesystem beyond the immediate image file.

Security policies in ImageMagick are defined in XML files that specify which operations and coders are permitted. Historically, many Linux distributions shipped with permissive policies to ensure compatibility with various workflows. This vulnerability highlights the danger of relying on system-level defaults for application security, especially when processing untrusted user input. The recent fix shifts the responsibility to the application framework by bundling a restrictive policy directly with Rails.

Why it matters

For teams running self-hosted Rails applications, this vulnerability represents a direct threat to infrastructure integrity. Unlike some bugs that require complex conditions to exploit, this one is triggered by the basic act of uploading a file. If your application accepts uploads from public users or even internal staff, it is potentially exposed. The ability for an attacker to write files means they could plant backdoors, modify application code, or exfiltrate data by reading configuration files.

The impact is compounded for applications using the Disk service, as the exposure of secrets like secret_key_base compromises the entire application’s security model. Once an attacker has these keys, they can forge session cookies, decrypt stored credentials, and impersonate users. This makes immediate remediation critical, as the window for exploitation is wide and the potential damage extensive. Furthermore, older Rails versions no longer receive security patches, forcing teams on legacy systems to find alternative mitigation strategies.

What you can do

• Upgrade immediately to Rails 8.1.4.1 or 8.0.5.2, and ensure mini_magick gem version 5.1 or later is installed.
• Verify that the new ImageMagick policy is active by running bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'.
• If you cannot upgrade, manually copy the restrictive policy from activestorage/lib/active_storage/image_magick/policy.xml to your system’s ImageMagick policy file.
• Rotate all secrets immediately if your app uses the Disk service, including secret_key_base, database credentials, and API tokens, as they may have been exposed.
• Check for custom ImageMagick configurations that might override the new restrictions, such as wildcards in policy.xml that re-enable blocked coders.
• Consider migrating to libvips if possible, as it is not affected by this specific ImageMagick-related vulnerability chain.