Critical Ruby on Rails Flaw CVE-2026-66066 Enables File Disclosure and Potential RCE

A newly disclosed critical security vulnerability in Ruby on Rails, tracked as CVE-2026-66066, poses a severe risk to web applications by allowing unauthenticated attackers to read arbitrary files from vulnerable servers and potentially escalate attacks to remote code execution (RCE).

The vulnerability affects Active Storage, the framework’s built-in file attachment component, when configured to use the libvips image processing library.

Because libvips has been the default image variant processor since Rails 7.0, the flaw impacts a significant number of modern Rails deployments that accept user-uploaded images.

Critical Ruby on Rails Flaw

Security experts warn that successful exploitation could expose highly sensitive server information, compromise application secrets, and ultimately lead to complete system takeover if organizations fail to apply available patches promptly.

The vulnerability originates from the way libvips processes image variants through its internal loader and saver operations.

According to the Rails security team, some of these operations are explicitly classified by libvips maintainers as “unfuzzed,” meaning they have not been thoroughly tested or hardened against malicious, untrusted input.

These unsafe operations were never intended to process attacker-controlled files. However, Active Storage’s default implementation failed to disable these vulnerable processing paths, creating an opportunity for attackers to exploit specially crafted image uploads.

By submitting a malicious image that triggers variant generation, an attacker can force libvips to execute one of these unsafe operations, resulting in unauthorized access to files stored on the application server.

Security researchers confirmed at least one practical exploitation chain capable of disclosing arbitrary files from the server’s filesystem.

Among the most valuable targets are environment configuration files containing sensitive secrets such as secret_key_base, database credentials, cloud storage authentication tokens, encryption keys, and third-party API credentials.

These files often reside within predictable application directories and provide attackers with everything needed to compromise the application beyond simple information disclosure.

Since exploitation requires no authentication under vulnerable configurations, internet-facing applications accepting image uploads are considered particularly exposed.

The disclosure of secret_key_base significantly increases the severity of the vulnerability. In Ruby on Rails, this cryptographic secret protects signed cookies, encrypted session data, password reset tokens, and Active Storage URLs.

If attackers obtain this key, they can forge authenticated sessions, impersonate privileged users, manipulate signed requests, and bypass application security controls.

Combined with access to additional credentials stored within environment variables or encrypted configuration files, attackers may achieve remote code execution, move laterally across cloud infrastructure, or gain unauthorized access to services such as Amazon S3, Google Cloud Storage (GCS), Microsoft Azure Blob Storage, databases, and other integrated enterprise systems.

Applications are considered vulnerable when three primary conditions are met. First, they use Active Storage for handling uploaded images.

Second, the application is configured to use libvips as the image variant processor through the setting config.active_storage.variant_processor = :vips, which has been the default configuration beginning with Rails 7.0. Finally, the application accepts image uploads from untrusted or unauthenticated users.

Notably, researchers emphasize that explicit image variant generation is not required for exploitation. Simply accepting uploaded images under the vulnerable configuration is sufficient to expose the application to attack, expanding the potential impact across a broad range of production environments.

The vulnerability affects Active Storage versions earlier than 7.2.3.2, versions 8.0 through 8.0.5.0, and 8.1 through 8.1.3.0. The Ruby on Rails security team strongly recommends upgrading immediately to the patched releases while also ensuring that libvips version 8.13 or later is installed.

Earlier libvips releases lack the capability to disable unsafe operations, making software updates essential. Patched versions of Active Storage now perform security validation during application startup and will generate a boot-time exception when an insecure libvips configuration is detected, preventing vulnerable deployments from operating unnoticed.

Beyond software updates, security teams should assume that sensitive credentials may already have been exposed if vulnerable systems processed untrusted uploads.

As a precaution, organizations should rotate secret_key_base, regenerate the Rails master key, replace credentials stored in credentials.yml.enc, rotate database passwords, renew API tokens, and replace cloud storage credentials associated with Amazon S3, Google Cloud Storage, Azure Blob Storage, and other integrated services.

Organizations unable to upgrade Rails immediately but already running libvips 8.13 or newer can temporarily mitigate the risk by enabling the VIPS_BLOCK_UNTRUSTED environment variable or calling Vips.block_untrusted(true) when using ruby-vips 2.2.1 or later.

Unfortunately, no effective workaround exists for libvips versions earlier than 8.13 other than completely removing the vulnerable dependency until a secure upgrade can be performed.