CVE-2026-66066: Pre-Authentication Arbitrary File Read and Remote Code Execution in Ruby on Rails Active Storage

Active Storage is a core component of the Ruby on Rails framework designed to manage file uploads, link files to Active Record models, and handle on-the-fly transformations such as thumbnail generation. When configured to process images using the libvips library via the ruby-vips gem, the framework delegates the decoding, modification, and re-encoding of uploaded media files to the underlying native engine.

The vulnerability, identified as CVE-2026-66066 and colloquially referred to as 'KindaRails2Shell', represents an insecure default initialization issue. Under default settings, Active Storage does not configure the libvips environment to restrict its input parsing capabilities. This omission allows remote, unauthenticated users to supply files in formats that trigger complex and poorly fuzzed internal parsing engines within the native library.

An attacker can abuse this behavior to trigger local file disclosure through external dataset features in complex file formats. By mapping system files directly into the color space of generated image variants, the attacker can extract cryptographic keys. These keys can subsequently be used to sign serialized payloads that exploit vulnerable deserialization mechanisms in Rails, leading to unauthenticated remote code execution.

The root cause of CVE-2026-66066 stems from how libvips manages its security boundaries for file format loaders. The native C library contains numerous parsing engines for specialized, scientific, or legacy formats. Because many of these loaders are complex or rely on third-party dependencies, libvips internally tags formats such as MATLAB/HDF5, PDF, SVG, and PSD as 'untrusted' or 'unfuzzed'. These formats are considered unsafe for use with untrusted network inputs.

Active Storage failed to invoke the security APIs provided by libvips to block these untrusted loaders. Consequently, when a Rails application receives an image upload, it relies on libvips to process the asset into a resized or reformatted variant. The native library performs magic byte sniffing on the input file, overriding the high-level MIME-type validation defined by the application developer.

This behavior allows an attacker to upload a malicious MATLAB/HDF5 file disguised as a standard image (such as a BMP). The MATLAB loader supports a feature called 'External Datasets', which allows matrices in the file to reference arbitrary physical file paths on the host filesystem. When libvips processes the uploaded file to generate a representation, the matload parser reads the targeted local files and encodes their raw byte contents directly into the RGB color channels of the resulting output image.

The official remediation introduces process-wide restrictions on the image-processing library upon application startup. The patch is applied in activestorage/lib/active_storage/vips.rb to ensure that untrusted format loaders are blocked globally.

The vulnerable versions did not contain any initialization code to restrict format processing. The patched implementation enforces the following initialization checks:

# frozen_string_literal: true
 
require "active_storage"
require "active_support/core_ext/string/filters"
 
if ActiveStorage::VIPS_AVAILABLE
  begin
    # image_processing 2.0 calls Vips.block_untrusted(true) itself when it loads,
    # so it has to load before the lines below.
    require "image_processing/vips"
  rescue LoadError
  end
 
  unless Vips.respond_to?(:block_untrusted)
    raise <<~ERROR.squish
      libvips's unfuzzed operations are not safe to use with untrusted content, and Active Storage
      cannot disable them. Disabling them requires libvips 8.13 or later and ruby-vips 2.2.1 or
      later. Please upgrade libvips and ruby-vips, or remove the ruby-vips gem from your Gemfile.
    ERROR
  end
 
  # This system-wide call globally disables unsafe format loaders/savers
  Vips.block_untrusted(true)
end

The code block demonstrates a fail-secure approach. The invocation of Vips.block_untrusted(true) configures the underlying C library to decline parsing any format classified as unfuzzed or untrusted. Furthermore, if the host environment uses an older version of libvips or the ruby-vips gem that lacks the block_untrusted method, the application raises a runtime error and refuses to start, preventing silent vulnerability exposure.

To exploit this vulnerability, an attacker first constructs a malformed MATLAB/HDF5 file that defines an external dataset mapping to a targeted local file, such as /proc/1/environ or /etc/passwd. The attacker uploads this file to the target Rails application through any public upload endpoint that handles attachments via Active Storage. The attacker then requests the representation URL for the variant to trigger image generation.

Upon receiving the request, the Rails server executes the variant processing pipeline. libvips reads the file header, identifies it as a MATLAB format, and executes the matload loader. The loader resolves the external dataset, reads the targeted system file, and writes its raw contents into the canvas memory buffer. The application then returns a standard PNG containing the system file's raw bytes embedded within the pixel values.

The attacker retrieves this image and decodes the pixel array to reconstruct the leaked environment variables, extracting the application's SECRET_KEY_BASE. Using this cryptographic secret and the default salt ActiveStorage, the attacker generates a signed variation parameter containing a serialized Ruby Marshal payload. This payload encodes a deserialization gadget chain. When sent to the Rails server, Active Storage verifies the signature, deserializes the parameter using Marshal.load, and triggers unauthenticated remote code execution on the host.

The impact of CVE-2026-66066 is critical, as it allows full compromise of the underlying application host and its connected systems. In the initial stage, the arbitrary file read capability allows attackers to extract system configurations, database credentials, environment files, and internal communication tokens.

Once the attacker extracts the SECRET_KEY_BASE, the security controls of the Rails application are completely bypassed. Since the key is used to sign and encrypt cookies, session parameters, and database columns, the attacker can forge administrative sessions, access sensitive customer records, and modify persistent application state.

Finally, the deserialization of the forged Marshal payload provides unauthenticated remote code execution. Because Active Storage frequently runs within background worker processes (such as Sidekiq or Solid Queue) or web server threads with elevated privileges, the execution of arbitrary commands can lead to complete host takeover, lateral movement within the network, and exposure of internal infrastructure.

Mitigation of the vulnerability requires upgrading Ruby on Rails to patched releases. The official patches are available in versions 7.2.3.2, 8.0.5.1, and 8.1.3.1. These updates must be accompanied by upgrading host dependencies to libvips >= 8.13 and ruby-vips >= 2.2.1 to ensure the security APIs are available.

If the application cannot be updated immediately, administrators can implement temporary workarounds. The primary workaround is to change the active variant processor from :vips to :mini_magick in the environment configuration file: config.active_storage.variant_processor = :mini_magick.

When switching to MiniMagick, administrators must secure the host's ImageMagick configuration by modifying the policy.xml file. The policy should explicitly block dangerous coders such as MSL, MVG, HTTPS, and PDF to prevent similar file-read and execution vectors within the alternate image processor.