CVE-2026-66066: Critical Vulnerability in Rails' Active Storage Framework
A critical vulnerability in the Active Storage framework used by the popular open-source web application framework Rails can allow an unauthenticated attacker to read arbitrary files from a Rails application, and potentially escalate to remote code execution (RCE).
Rails is a widely-used framework for building websites and web applications, and it uses the built-in Rails component Active Storage for handling file uploads and attachments. According to the security bulletin, the CVE-2026-66066 flaw is exploitable when the image processing library libvips is used, allowing an attacker to upload a specially crafted image to a vulnerable application and read arbitrary files on the server.
Requirements for Exploitation
Another prerequisite for the attack is that the server needs to allow image uploads from untrusted users. If these requirements are met, an attacker may access app files, including the process environment, which typically contains sensitive information such as the 'secret_key_base' and credentials for databases, cloud storage, and other services.
The CVE-2026-66066 vulnerability impacts Active Storage before 7.2.3.2, 8.0.x before 8.0.5.1, and 8.1.x before 8.1.3.1. Rails 6.x is only affected if Active Storage has been configured outside its defaults.
Mitigation and Recommendations
The Rails team recommends upgrading to libvips 8.13 or later and rotating the 'secret_key_base' (the Rails master key), database credentials, Active Storage service credentials, and any other secrets accessible to the application process. For systems running libvips 8.13 or later, administrators can temporarily disable the vulnerable functionality by setting the VIPS_BLOCK_UNTRUSTED environment variable or calling Vips.block_untrusted(true) when using ruby-vips 2.2.1 or newer.
There is no workaround available for apps that use libvips before 8.13. ImageMagick users are not affected by this vector. However, libvips is the default processor in the official Rails Docker images, and also Debian and Ubuntu setups.
Disclosure and Response
The Rails team has intentionally withheld technical details for the vulnerability to reduce the risk of exploitation before users have time to apply the updates. Full technical details were initially scheduled to be disclosed on August 28 on the Rails forums. However, because public proof-of-concept (PoC) exploits became available very quickly, the maintainers decided to publish the full details as well as forensic investigation tooling.
The vulnerability was discovered and responsibly reported to the Rails team by researchers from Ethiack and GMO Flatt Security Inc. Security firm Akamai has also published a warning about CVE-2026-66066, naming the attack chain 'KindaRails2Shell,' and warning about its RCE potential.
With the secret_key_base compromised, the attacker holds the master cryptographic key to the application. They can forge session cookies, sign global IDs, and manipulate serialized data, which directly translates into full RCE on the underlying server.
Akamai says it coordinated with Ethiack before public disclosure to prepare protections for customers, and has now released web application firewall (WAF) protections. Ethiack noted that a WAF might buy admins some time, but attackers using AI tooling should be able to reconstruct the attack chain based on the patch diffs.
- Test every layer before attackers do
- Security teams log 54% of successful attacks and alert on just 14%
- The rest move through your environment unseen
The Picus whitepaper shows how breach and attack simulation tests your SIEM and EDR rules so threats stop slipping by detection.
Source: BleepingComputer