A critical vulnerability in the Ruby on Rails web application framework could allow unauthenticated attackers to read sensitive files and potentially seize control of applications by uploading malicious images disguised as legitimate files. The flaw, disclosed July 30 by CSO Online, scored 9.5 out of 10 on the severity scale and poses significant risk to enterprises running apps that handle user-uploaded images in Rails. Dubbed "KindaRails2Shell," the vulnerability targets the Active Storage component of the open-source framework, enabling attackers to escalate from file access to remote code execution.
The vulnerability, CVE-2026-66066, exploits the way Active Storage interacts with the libvips image processing library to generate images. Libvips contains "unfuzzed" operations that haven't been hardened against malicious inputs, making them unsafe for untrusted content, but Active Storage doesn't adequately disable them. Applications are impacted when they're configured to use libvips for Active Storage image processing—the default behavior since Rails 7.0—and accept image uploads from untrusted or unauthenticated users. The issue has been fixed in versions 7.2.3.2, 8.0.5.1, and 8.1.3.1 of Active Storage, and enterprises running Rails should update immediately. Upgrading Rails alone isn't sufficient when an older libvips installation remains underneath it; libvips must be version 8.13 or later.
"CVE-2026-66066 is particularly dangerous because an attacker may not need an account or privileged access," explained Ensar Seker, CISO at SOCRadar, according to the report. Attackers can exploit the unsafe pipeline by uploading specially crafted files that trick Active Storage into giving them access to files the Rails process is permitted to access, including environment variables, database credentials, cloud access keys, and API tokens. "The immediate vulnerability is an arbitrary file-read issue, but the theft of secrets such as Rails' secret_key_base can turn information disclosure into a much broader compromise," Seker said. David Shipley of Beauceron Security noted that attackers can "upload an image that isn't actually an image [but] is code that allows them to steal secrets."
The vulnerability is critical because attackers can gain access to the secret_key_base that signs and encrypts cookies, credentials, and session data. When secret_key_base is compromised, attackers essentially hold the key to the application, the report explains. Depending on the application, attackers could potentially forge trusted application data or sessions, access databases and cloud services, move laterally into connected systems, or achieve remote code execution. That escalation path is what makes the vulnerability critical—a seemingly routine image upload feature, such as a profile picture or avatar, could become an entry point into the application's underlying infrastructure. Complex image libraries support many formats and rely on numerous parsers and third-party components, creating a broad attack surface that should be treated as untrusted code execution territory, the report notes.
Security teams should treat this as a potential secret-exposure incident, not merely a patch-management exercise, the report advises. Organizations should audit every internal and third-party app to determine whether they're configured to use libvips with Active Storage, examine app logs for suspicious uploads, and rotate secret_key_base and every other credential available in Rails. When a vulnerability enables arbitrary file access, installing the patch closes the entry point but doesn't revoke credentials that may already have been copied, the report warns. Because several researchers reverse-engineered the attack and published proof of concept code, Rails disclosed technical details about the flaw nearly a month earlier than planned, and the availability of proofs of concept materially increases the likelihood of opportunistic scanning and exploitation attempts. Even organizations that see no obvious evidence of compromise shouldn't assume that patching alone removes the risk created by previously exposed secrets. The disclosure timing disruption reflects a broader shift in how vulnerability information spreads once technical details leak, forcing security teams to accelerate response plans even when they believed they had more runway.