Rails fixed CVE-2026-66066, a critical Active Storage flaw that could let unauthenticated attackers read arbitrary files via crafted image uploads.
On July 29, Ruby on Rails released a security advisory fixing a critical vulnerability in the Active Storage component, CVE-2026-66066, rated Critical with a CVSS score of 9.5. The core issue is not ordinary file uploading; rather, when an application uses libvips as its image-processing library and allows untrusted users to upload images, an attacker can use a specially crafted file to read arbitrary files on the server. If the file contains environment data accessible to the Rails process, the risk expands directly to leakage of keys, credentials, and cloud tokens.[3][5][7]
According to public information, the patched versions include Active Storage 7.2.3.2, 8.0.5.1, and 8.1.3.1. Administrators must also upgrade libvips to version 8.13 or later to complete the protection chain. The related guidance also notes that simply upgrading Rails may not be sufficient, because exploitability depends on the implementation of the image-processing pipeline.[3][5][7]
The technical focus of this incident is the interface between Active Storage and libvips. Active Storage handles file uploads, attachment management, and image variant processing; when it uses libvips to process user-uploaded images, improper restriction of untrusted input can allow an attacker to turn an "image upload" into a gateway for arbitrary server-side file reads.[1][5][9]
Public research and community advisories both state that the affected scenario has clear conditions: Active Storage must be enabled, the variant processor must be set to :vips, and untrusted users must be allowed to upload images. Ethiack and the Ruby on Rails community advisories also note that this risk chain is closely tied to Rails 7.x/8.x image variant processing; by contrast, Rails 6.x is only at risk if Active Storage is manually configured to use libvips and accept untrusted image uploads.[1][5]
In terms of impact, if an attacker succeeds in reading the Rails process environment, the most valuable targets are often secret_key_base, the Rails master key, database credentials, cloud storage service keys, and third-party API tokens. These secrets may not only give the attacker continued access to application data, but may also become a stepping stone toward remote code execution (RCE) or lateral movement.[2][5][7]
Some research describes this issue as involving arbitrary file read and remote code execution risk; this means the file-read flaw alone is already enough to cause severe leakage, and if leaked secrets can later be used to control the application or connected services, the attack may escalate further.[1][2][7]
Based on multiple sources, the affected versions mainly include activestorage < 7.2.3.2, >= 8.0.0.beta1, < 8.0.5.1, and >= 8.1.0.beta1, < 8.1.3.1. The fixed versions are 7.2.3.2, 8.0.5.1, and 8.1.3.1.[2][9]
In addition, Rails 6.x is generally not affected in a standard default installation, but it may still fall within the risk scope if Active Storage is customized to use libvips and accept untrusted image uploads. This means that in practice, one cannot rely only on the major version number; the actual Active Storage and image-processing configuration must also be checked.[1][2]
The primary affected targets are applications that support image uploads and use libvips for backend variant processing. Any application that allows unauthenticated or low-trust users to upload images should be treated as a high-risk asset.[1][5][7]
The most direct and necessary measure is to update Rails and Active Storage to the patched versions, and at the same time confirm that libvips has been upgraded to 8.13 or later. Multiple advisories emphasize that the patch is not a single-point update; the framework and the underlying image-processing package must both be included in the remediation scope.[3][5][7]
The second step is to immediately inventory all secrets readable by the Rails process, including secret_key_base, the Rails master key, database passwords, cloud storage credentials, and third-party tokens, and rotate them after patching. Once these values may have been exposed, simply fixing the vulnerability is not enough to eliminate the existing exposure.[2][5][7]
The third step is to check whether the application truly needs to allow untrusted users to upload images, and whether libvips is truly required for image processing. If business requirements allow, the upload surface should be reduced to minimize the attack surface for similar issues in the future.[1][5][9]
The fourth step is to review logs for signs of abnormal uploads, file reads, or credential usage, and to inspect application-layer, storage-layer, and cloud credential activity logs in parallel.[2][5][7]
libvips are within the affected range, and prioritize upgrading to 7.2.3.2, 8.0.5.1, or 8.1.3.1.[3][5][7]libvips to 8.13 or later so that only updating Rails does not leave the underlying library unaddressed.[3][5][7]secret_key_base, the Rails master key, database credentials, and cloud tokens.[2][5][7]