Unauthenticated attackers can execute arbitrary code through malicious image uploads in Rails Active Storage

Summary

A high-severity vulnerability in Ruby on Rails' Active Storage component enables an attacker to exfiltrate sensitive data, such as secret_key_base, through a crafted file upload. By exploiting the way Active Storage interacts with the libvips image processor, attackers can trigger an arbitrary file-read oracle. This exposure of environment variables and application secrets can be escalated to remote code execution (RCE).

The vulnerability affects applications configured to use libvips as their variant processor. While Rails 7.0 and later use libvips by default, the issue specifically impacts how untrusted uploads are handled during representation requests.

Technical Details

The attack chain relies on two distinct trust failures within the Active Storage workflow. First, the standard direct-upload endpoint accepts a content_type directly from the client request and writes it to the database without verifying the actual file bytes via server-side unfurling. This allows an attacker to upload a crafted MATLAB/HDF5 file while claiming it is a standard image/png.

Second, because Rails resolves signed blob IDs and signed variation keys independently, an attacker can replay a genuine variation_key from any representation URL against their newly created malicious blob. There is no cross-check between these two signed values.

When the application attempts to generate a variant for this blob, it hands the file path to libvips. Because Active Storage does not disable "unfuzzed" operations that are marked unsafe for untrusted content, libvips can be coerced into reading arbitrary files from the filesystem. An attacker can use these reads to extract sensitive data and then forge a signed ImageProcessing variation to achieve code execution via Kernel#spawn or Kernel#eval.

Affected Products and Fixed Versions

The vulnerability affects specific version ranges of Active Storage where libvips is used for processing.

Defender Guidance

Immediate action is required for any Rails application using libvips for image processing.

1. Upgrade Rails Update your Active Storage component to the fixed versions listed above: 7.2.3.2, 8.0.5.1, or 8.1.3.1.

2. Rotate All Secrets Upgrading prevents future exploitation but does not invalidate secrets already stolen via this flaw. You must treat every secret accessible to the Rails process as compromised. This includes:

• The secret_key_base (this will expire active sessions and require users to log in again).
• The master.key or any values in config/credentials.yml.enc.
• Credentials for external services like S3, GCS, or Azure.
• Any third-party API tokens used by the application.

3. Apply Immediate Mitigations (If Upgrade is Delayed) If you cannot upgrade immediately and are using libvips >= 8.13, you can disable unfuzzed operations by setting the following environment variable: VIPS_BLOCK_UNTRUSTED=true

Alternatively, if running ruby-vips >= 2.2.1, add this to a Rails initializer: Vips.block_untrusted(true)

If you are using a version of libvips older than 8.13, these mitigations are not available; the only workaround is to remove the dependency on libvips.