Rails CVE-2026-66066: patch Active Storage today

If you run a Rails app that accepts image uploads, stop reading the rest of the internet and go check your version. CVE-2026-66066 is a CVSS v4 9.5 flaw in Active Storage that lets an unauthenticated attacker read arbitrary files off your server with a crafted image. The Rails team published the advisory on July 29. Today they published the attack mechanics and the forensic tooling — weeks ahead of the planned disclosure date, because researchers had already reverse-engineered the patch.

What actually happened

The bug lives in Active Storage variant processing when your app uses libvips for image transformation. Upload a specially crafted file, and the processing pipeline can be steered into reading files it was never supposed to touch. Rapid7's writeup — they're calling it KindaRails2Shell — lists the affected ranges: Rails 7.0.0 through 7.2.3.1, 8.0.0 through 8.0.5, and 8.1.0 through 8.1.3. Rails 6.0–6.1 are affected only under a non-default Vips config. Fixed versions are 7.2.3.2, 8.0.5.1, and 8.1.3.1, and the fix requires libvips 8.13 or later to actually work.

Arbitrary file read sounds survivable until you list what's readable in a typical Rails deployment: secret_key_base, the master key, config/credentials, database URLs, S3 keys, and whatever API tokens are sitting in the environment. With secret_key_base in hand, an attacker can forge signed cookies and sessions. That's the path from "read a file" to remote code execution, and it's why the CVSS is 9.5.

Rapid7 said it was not aware of in-the-wild exploitation as of July 30. Public proof-of-concept code has since appeared. Treat that gap as closed.

Why this Rails CVE matters for your business

Most small-business Rails apps hit every condition in this advisory: they use Active Storage, they take user uploads, and nobody has looked at the image processing backend since the app was generated. If you can't upgrade this hour, the stopgap is real — set VIPS_BLOCK_UNTRUSTED in the environment on libvips 8.13+, or call Vips.block_untrusted(true) from an initializer if you're on ruby-vips 2.2.1 or newer. Do that now and upgrade properly after.

Then do the part most teams skip. Rails shipped two forensic tools, built from 37signals' own internal investigation: one that determines whether your app was ever vulnerable and for exactly what window, and one that searches your Active Storage data for the crafted files and works out what was read if it finds them. The attack leaves evidence in your database and your object store. That's an unusually generous thing for a framework team to hand you — most advisories say "patch" and leave you guessing about the four months before you did.

Order of operations: patch, rotate every secret the app could read, then run the forensics. Rotating after you've confirmed a breach is a month too late.

Sources: Ruby on Rails security announcement, Rapid7.