Critical Ruby on Rails Vulnerability Could Allow Unauthenticated Attackers to Read and Write Server Files

A critical security vulnerability in Ruby on Rails could allow unauthenticated attackers to write arbitrary files to application servers and potentially access sensitive data by uploading specially crafted files. The flaw affects applications that use Active Storage with ImageMagick for image processing and could ultimately lead to remote code execution or compromise of connected systems.

Tracked as GHSA-f3w6-w445-fwh9, the vulnerability carries a CVSS score of 9.8 out of 10, placing it in the critical severity category. Rails disclosed the issue in a security advisory and released fixes in versions 8.1.4.1 and 8.0.5.2. No CVE identifier has been assigned at the time of disclosure.

The vulnerability resides in Active Storage, the framework’s built-in component for handling file uploads. Applications using Active Storage’s Disk service, which stores uploaded files directly on the server’s filesystem, face particularly serious risks. Successful exploitation could allow attackers not only to overwrite arbitrary files but also to read files accessible to the application process.

Such access could expose highly sensitive information, including Rails’ secret_key_base, application master keys, database credentials, cloud storage credentials, and third-party service tokens. Depending on the permissions and exposed secrets, attackers could leverage this information to execute code remotely, impersonate application components, or move laterally into connected infrastructure.

ImageMagick Processing Opens the Door to File Manipulation

The underlying issue involves how ImageMagick identifies and processes uploaded files.

ImageMagick uses format-specific handlers, known as coders, to determine how a file should be interpreted. Some of these coders can perform operations involving files other than the uploaded image itself, including reading and writing files specified within the input.

According to the Rails security advisory, Active Storage did not sufficiently restrict which ImageMagick coders could process uploaded content. Consequently, the application’s own ImageMagick security policy was effectively the primary barrier preventing potentially dangerous operations.

Researchers demonstrated an attack path involving an uploaded SVG file that reached ImageMagick’s Machine Script (MSL) coder through Active Storage’s image analyzer. MSL supports scripted image operations, including reading from and writing to specified filesystem paths.

Importantly, exploitation does not require an application to generate image variants, create previews, or explicitly invoke the analysis process. The vulnerability can be triggered simply by attaching an uploaded file, because Active Storage automatically analyzes attachments.

Rails acknowledged receiving a report describing one exploitation technique but cautioned that other attack paths may exist.

The vulnerability was reported through HackerOne by RyotaK, a security researcher at GMO Flatt Security.

Which Applications Are Vulnerable?

Not every Ruby on Rails application is affected. Exploitation requires three conditions to be present simultaneously:

• The application uses ImageMagick through Active Storage’s MiniMagick integration for image processing.
• The installed ImageMagick security policy does not block the dangerous coders involved in the attack.
• The application accepts file uploads from untrusted users.

The relevant configuration setting is config.active_storage.variant_processor.

Applications using :mini_magick are potentially vulnerable, while applications using :vips do not follow this particular ImageMagick attack path.

The default processor depends on the Rails configuration defaults. Applications using load_defaults 6.1 or earlier generally default to MiniMagick, while applications using Rails 7.0 defaults or later use Vips unless explicitly configured otherwise.

All Active Storage versions before 8.0.5.2 are affected, as are versions in the 8.1 series before 8.1.4.1. Older release branches are no longer supported and will not receive dedicated fixed releases.

The disclosure also highlights an important distinction between this vulnerability and a separate critical Active Storage flaw addressed in July 2026, tracked as CVE-2026-66066. That earlier issue affected applications using libvips, whereas the newly disclosed vulnerability targets applications relying on ImageMagick.

A Second Active Storage Vulnerability Also Fixed

The same Rails releases address another Active Storage security issue, tracked as GHSA-v924-7rp8-4mxh, with a CVSS score of 8.8.

This vulnerability involves how Active Storage passes uploaded files to external processing tools, including ImageMagick and FFmpeg.

Temporary filenames retained the original file extension, potentially allowing attackers to influence which decoder a processing tool selected when the file’s contents did not clearly identify its actual format.

By controlling both the uploaded filename and declared content type, an attacker could potentially influence how the external processing utility interprets the uploaded content.

Rails stated that the two vulnerabilities are among 21 security issues addressed by the latest releases, making the updates particularly important for organizations operating production applications. Details here: https://www.openwall.com/lists/oss-security/2026/11/04/2

What Organizations Should Do

Rails strongly recommends upgrading affected applications immediately to Rails 8.1.4.1 or 8.0.5.2.

Organizations using MiniMagick should also ensure that they run MiniMagick 5.1 or later, as the updated Rails integration requires this version to apply the new security protections correctly.

Administrators should verify that the application loads the security policy included with the patched Active Storage releases. Rails provides the following command for checking the active ImageMagick policy:

bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'

The updated policy blocks the MSL coder, dangerous coders capable of accessing or deleting external files, coders that retrieve remote or local references, Ghostscript-backed coders, and the gs delegate. It also restricts filename indirection mechanisms.

However, deploying the update alone may not be sufficient in customized environments.

Applications that override MiniMagick’s command environment, replace its shell implementation, or otherwise bypass the default configuration may fail to load the bundled policy. In such cases, administrators should ensure the required restrictions are configured directly in ImageMagick’s system-level policy.xml file.

Organizations should also review their existing ImageMagick policies. Custom rules that explicitly permit restricted coders, including wildcard permissions, may override the protections introduced by Rails.

Applications using GraphicsMagick instead of ImageMagick should not assume they receive the same protection, as GraphicsMagick does not interpret ImageMagick security policies.

For organizations unable to upgrade immediately, Rails recommends applying the security restrictions from the bundled Active Storage policy directly to the server’s ImageMagick configuration. At a minimum, administrators should block MSL, Ghostscript-related coders, and the Ghostscript delegate.

Rotate Credentials If Exposure Is Suspected

Organizations operating affected applications with Active Storage’s Disk service should also consider the possibility that application-readable files may have been accessed.

If exploitation is suspected, simply patching Rails is not enough. Security teams should rotate secret_key_base, the application master key, database credentials, storage access keys, and all third-party tokens accessible to the application process.

Previously exposed credentials should not be retained as fallback secrets.

Organizations should additionally investigate application logs, upload activity, filesystem changes, and unusual interactions with connected services to identify potential signs of compromise.

The vulnerability highlights the security risks associated with processing untrusted files through powerful third-party utilities. Even when an application framework provides built-in upload functionality, the underlying image-processing tools can introduce dangerous capabilities if their supported operations are not sufficiently restricted.

With a CVSS score of 9.8 and an attack path that may require nothing more than attaching a malicious file, organizations using affected Rails configurations should prioritize patching, verify their ImageMagick security policies, and review potentially exposed credentials without delay.