A flaw in Ruby on Rails Active Storage lets unauthenticated attackers read arbitrary files through crafted image uploads, a vulnerability tracked as CVE-2026-66066 that could lead to remote code execution. The issue was disclosed in the official Rails security advisory GHSA-xr9x-r78c-5hrm and affects applications that process untrusted images.
The problem lies in how Active Storage hands off files to the libvips image processor, which fails to properly sanitise filenames or metadata. Versions earlier than 7.2.3.2, 8.0.5.1 and 8.1.3.1 are vulnerable, and the flaw has been assigned a CVSS score of 9.5 indicating a high level of risk. Details were highlighted in a report by securityonline.info which noted that directory traversal can be triggered by a malicious image.
Exploitation requires the target Rails application to accept image uploads and use Active Storage for processing. By embedding a specially crafted path within an image’s metadata, an attacker can trick libvips into reading files outside the intended storage directory. This could expose secret keys, configuration files or source code that might then be used to achieve remote code execution.
As of the advisory’s publication, no instances of active exploitation have been observed and no specific threat actors have been linked to the vulnerability. The issue impacts any Rails service that relies on image uploads, ranging from public facing content management systems to internal employee portals. Coverage by thehackernews.com emphasised the potential for data leakage in environments that trust user supplied images.
The advisory recommends upgrading to the patched releases as the primary defence and rotating any application secrets that may have been exposed. Users should also verify that their upload validation rules restrict file types to genuine images and consider limiting the size of accepted files to reduce the attack surface.
Administrators are advised to apply the upgrades to Rails 7.2.3.2, 8.0.5.1 or 8.1.3.1 or newer without delay, review their Active Storage configuration for overly permissive settings and place upload endpoints behind a web application firewall that can block anomalous requests. Finally, any credentials, encryption keys or API tokens stored on the server should be rotated as a precautionary measure in case they were accessed during the window of exposure.