Critical Ruby on Rails Vulnerability Could Allow Unauthenticated Server File Writes and Data Theft

Cybersecurity researchers have disclosed a critical vulnerability in Ruby on Rails that could allow unauthenticated attackers to write arbitrary files to application servers by uploading specially crafted files. Under certain configurations, successful exploitation could also expose sensitive files and credentials, potentially leading to remote code execution or further compromise of connected systems.

The vulnerability affects Active Storage, the Rails component responsible for handling file uploads. It occurs when applications use ImageMagick to analyze uploaded files without sufficiently restricting the image-processing formats that can be handled.

The Rails project disclosed the issue in a security advisory and released fixes in versions 8.1.4.1 and 8.0.5.2.

Tracked as GHSA-f3w6-w445-fwh9, the vulnerability has a CVSS severity score of 9.8 out of 10. It has not yet received a CVE identifier.

How the Vulnerability Works

Active Storage supports different services for handling uploaded files. Applications using its Disk service store attachments directly on the server's filesystem.

The vulnerability involves how Active Storage interacts with ImageMagick during file analysis. ImageMagick selects a format handler, known as a coder, based on the uploaded file's content. Some coders can interact with files referenced inside the input rather than processing only the image itself.

Active Storage did not sufficiently restrict which ImageMagick coders could process uploaded files, leaving the server's ImageMagick security policy as the primary protection.

Researchers found that a malicious SVG upload could reach ImageMagick's MSL coder through Active Storage's image analyzer. MSL is a scripting-based format capable of reading and writing files specified by its instructions.

Importantly, an attacker does not need to generate an image variant, create a preview or manually trigger file analysis. Attaching the malicious upload is sufficient to reach the vulnerable processing path.

For applications using Active Storage's Disk service, exploitation could also allow attackers to read files accessible to the application process. These may include:

  • secret_key_base
  • Application master keys
  • Database and storage credentials
  • Encrypted application credentials
  • Third-party service tokens

Exposure of these secrets could enable further attacks, including remote code execution and lateral movement into connected systems.

Rails stated that one exploitation chain had been reported, but warned that other attack paths might also exist. The advisory does not confirm whether the vulnerability has been exploited in the wild.

The issue was reported through HackerOne by security researcher RyotaK of GMO Flatt Security.

Which Ruby on Rails Applications Are Affected?

An application is vulnerable when all three of the following conditions are met:

  1. It uses ImageMagick for Active Storage image processing through the :mini_magick variant processor.
  2. Its ImageMagick security policy does not block the vulnerable coders involved in the attack.
  3. It accepts file uploads from untrusted users.

Administrators can inspect the following configuration:

config.active_storage.variant_processor

If the setting is not explicitly configured, its default depends on the application's Rails compatibility settings. Applications using load_defaults versions before 7.0 default to :mini_magick, while newer defaults use :vips.

The setting also determines which library analyzes uploaded files, not just which library generates image variants.

According to the advisory, all Active Storage versions before 8.0.5.2 are affected, as are 8.1 releases before 8.1.4.1. Older release series before 8.0 are no longer supported and will not receive fixed releases.

A Second Active Storage Vulnerability Also Fixed

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

This issue involved Active Storage passing uploaded files to ImageMagick and FFmpeg using temporary filenames that retained the original file extensions.

When the file content does not clearly identify its format, these tools may select a decoder based on the filename extension. Attackers could therefore influence which decoder processes an upload by controlling its filename and declared content type.

The latest fixes address both vulnerabilities. Rails also reported that the releases resolve a total of 21 security issues.

How to Protect Ruby on Rails Applications

Rails strongly recommends upgrading affected applications as soon as possible.

The fixed releases include an ImageMagick security policy designed to restrict dangerous operations. The policy blocks the MSL coder, coders that interact with external files, remote or local references, Ghostscript-backed coders, the gs delegate and @filename indirection.

Administrators should take the following steps:

  • Upgrade Rails: Move to Rails 8.1.4.1 or 8.0.5.2. Applications using :mini_magick also require MiniMagick 5.1 or later to avoid startup errors.
  • Verify the security policy: Confirm that the application loads the updated ImageMagick policy using the command documented by Rails:
  • bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'
  • Inspect custom configurations: Applications that replace MiniMagick.cli_env, clear the environment through MiniMagick.cli_prefix or install a custom MiniMagick::Shell may not receive the shipped policy. These applications must configure the required restrictions in ImageMagick's system policy.
  • Review ImageMagick rules: The shipped policy supplements the existing system policy rather than replacing it. Existing rules that allow dangerous coders, including wildcard rules such as pattern="*", may override the intended restrictions.
  • Check GraphicsMagick usage: The supplied policy does not protect applications using GraphicsMagick because it does not read ImageMagick security policies.
  • Review PDF and PostScript processing: Applications that process these formats through ImageMagick may need to explicitly re-allow the gs delegate and associated coders in their system policy.
  • Apply temporary mitigations: If an immediate upgrade is not possible, administrators can copy the relevant restrictions from activestorage/lib/active_storage/image_magick/policy.xml into the system ImageMagick policy, such as /etc/ImageMagick-7/policy.xml. At a minimum, block the MSL coder, Ghostscript coders and the gs delegate.
  • Upgrade unsupported Rails versions: Applications running release series older than 8.0 should apply the documented workaround or upgrade to a supported release.

Rails has also published patches for the 8.1 and 8.0 release branches.

Rotate Secrets if the Application May Have Been Compromised

Applications using Active Storage's Disk service should take additional precautions if exploitation is suspected.

Because attackers may be able to read files accessible to the application process, administrators should rotate secret_key_base and all other secrets that the application could access. This includes master keys, encrypted credentials, database and storage credentials, and third-party service tokens.

Previously exposed credentials should not be retained as fallback secrets.

The Rails advisory does not provide a specific method for determining whether an application has already been targeted. Organizations should therefore review their available application and server logs, investigate suspicious file uploads and assess whether sensitive credentials may have been exposed.

The vulnerability highlights the security risks associated with unrestricted file processing in web applications. Developers should treat uploaded files as untrusted input and ensure that image-processing libraries operate under restrictive security policies.