Rails shipped fixes for CVE-2026-66066 in late July 2026, and the flaw would probably have stayed a footnote in a changelog if the mechanism behind it weren't so unusual. According to Rapid7's technical writeup and Akamai's analysis, the bug isn't a single coding mistake - it's a disagreement between four different pieces of software about what kind of file they're looking at, and an attacker who can make all four wrong at once.
Four libraries, one file, four different opinions
The exploit works by crafting a file with a MATLAB 5.0 header wrapped around an HDF5 v7.3 container - a dual-identity file that different parsers read differently. Inside that container sits an external dataset reference pointing at an arbitrary path on the server's filesystem. When Rails' Active Storage passes the upload to libvips to generate an image variant (a thumbnail, for instance), libvips's HDF5 handling - via libmatio - resolves that external reference and reads the target file's bytes in as if they were image pixel data. The attacker never touches the filesystem directly; they just ask Active Storage to make a thumbnail, and the thumbnail-generation code does the reading for them.
Nobody chose to be exposed - it's just the default
What makes this different from a typical "outdated dependency" CVE is that libvips has been Active Storage's default image variant processor since Rails 7.0. Any application built on Rails 7 or later that accepts image uploads from the public - avatars, attachments, support tickets, product photos - is exposed out of the box, without an engineering team having made an active decision to install or configure libvips at all. Rails 6 applications are only affected if they explicitly opted into Vips, which at least confines the blast radius there to teams who made a deliberate choice.
From file read to session forgery to RCE
Reading arbitrary files is bad enough on its own for anything holding credentials or configuration on disk, but the attack chain documented by researchers goes further: an attacker who reads secret_key_base - the value Rails uses to sign and encrypt session cookies - can forge valid signed sessions, impersonate any user, and in many application configurations escalate that into remote code execution or lateral movement into connected systems. The file-read primitive is the door; the secret key is what turns it into the rest of the house.
Patching Rails is necessary. It is not sufficient.
This is the detail most likely to get missed in a routine dependency bump. Akamai's guidance is blunt on the point: "Simply upgrading Rails is not enough protection if a compromise has already occurred. Administrators must assume that environment secrets have been exposed" and rotate them - secret_key_base, database credentials, API tokens - as a precaution, not just apply the patch and move on. Fixed Active Storage releases also depend on running libvips 8.13 or later; upgrading Rails while leaving an older libvips binary in place leaves the vulnerable parsing path intact underneath the patched framework code.
The proof-of-concept is already public
A working exploit for CVE-2026-66066 is published on GitHub, and SecurityWeek reports the flaw is already drawing attacker attention. As with most critical Rails CVEs, the gap between disclosure and mass scanning tends to be measured in days, not months - which makes "we'll patch it in the next sprint" a much riskier default than it sounds.
- Upgrade to Active Storage 7.2.3.2, 8.0.5.1 or 8.1.3.1 or later, matching your current Rails major/minor version.
- Confirm libvips is at version 8.13 or later on every host that processes uploads - a patched Rails on an old libvips is still vulnerable.
- Rotate
secret_key_base, database passwords and API tokens on any application that accepted untrusted image uploads before patching, on the assumption that secrets may already be exposed. - Audit every public-facing upload endpoint (avatars, attachments, support tickets) for whether it triggers Active Storage variant processing on untrusted files.
- Where an immediate upgrade isn't possible, apply vendor virtual-patching rules (Akamai published Rapid Rule 3000989) as a stopgap, not a substitute.
KindaRails2Shell is a reminder that "default configuration" and "safe configuration" are not the same claim - a theme we explored from a different angle in our piece on the TeamCity RCE that vendors initially said wasn't being exploited. If you need help auditing where Active Storage, or file-upload handling more broadly, sits in your Rails estate, email sales@halfteck.com.