Rails fixes a critical vulnerability in Active Storage that allows reading files and executing remote code
The Ruby on Rails maintenance team has published a security advisory for a critical-severity vulnerability in Active Storage, the framework component responsible for managing file and attachment uploads. The flaw, registered as CVE-2026-66066, allows an unauthenticated attacker to read arbitrary files from the server and, under certain conditions, escalate the attack to achieve remote code execution (RCE). The threat has been dubbed “KindaRails2Shell” by the security firm Akamai.
What the flaw allows exactly
Active Storage uses image-processing libraries such as libvips or ImageMagick to generate thumbnails of the multimedia files uploaded by users. According to the security bulletin published by the Rails team, the vulnerability is exploitable when the application uses libvips: an attacker can upload a specially crafted image that allows them to read arbitrary files from the server where the application runs.
The prerequisite is that the application allows image uploads by untrusted users, something common in forums, social networks, ticketing systems or any platform with user profiles. If these conditions are met, the attacker can access the content of the application process, including the runtime environment, which normally contains the “secret_key_base” variable, as well as database credentials, cloud services and other internal tools.
Affected versions and real scope
The vulnerability affects Active Storage in versions prior to 7.2.3.2, in 8.0.x versions prior to 8.0.5.1 and in 8.1.x versions prior to 8.1.3.1. In the case of Rails 6.x, it is only affected if Active Storage has been configured outside its default values.
The scope is broad: libvips is the default image processor in the official Docker images for Rails, as well as in Debian and Ubuntu installations. ImageMagick users are not affected by this particular vector. Given this situation, the Rails team recommends updating to libvips 8.13 or later and immediately rotating the “secret_key_base” —the application’s master key— as well as database credentials, Active Storage service credentials and any other secret accessible from the application process.
For systems already running libvips 8.13 or a higher version, there is a temporary mitigation: 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. Applications using libvips versions earlier than 8.13 have no workaround other than upgrading.
From file reading to code execution
Although arbitrary file reading is already serious on its own, the real danger comes when the attacker obtains the “secret_key_base”. As Akamai explains, with that master key compromised, the attacker can forge session cookies, sign Global IDs and manipulate serialized data, which translates directly into remote code execution on the underlying server. In practice, a vulnerable application can end up completely compromised.
The Rails team had initially decided to withhold the technical details of the vulnerability to reduce the risk of exploitation before administrators could apply the patches, with full disclosure planned for 28 August. However, the rapid appearance of public proof-of-concept (PoC) exploits forced those responsible to bring forward the publication of the full details, along with forensic tools to investigate possible compromises.
Race against automated attackers
The vulnerability was discovered and responsibly disclosed to the Rails team by researchers from Ethiack and GMO Flatt Security Inc. Akamai coordinated with Ethiack before the public disclosure to prepare protections for its customers and has already released rules for its web application firewalls (WAF).
Nevertheless, the researchers themselves warn that a WAF only buys time. Attackers using AI-based tools should be able to reconstruct the attack chain from the patch diffs, so the protection window is limited. The lesson for development teams is clear: update image-processing dependencies, rotate master keys as soon as possible and treat any upload of files from untrusted users as a high-risk attack surface.
