Critical Rails Flaw (CVE-2026-66066) Lets Unauthenticated Attackers Read Server Files via Image Uploads
A CVSS 9.5 vulnerability in Rails Active Storage lets attackers exploit libvips image processing to read arbitrary files, including secret_key_base. Patches are out for the 7.2, 8.0, and 8.1 branches.
The Rails security team disclosed CVE-2026-66066 on July 29, a critical flaw in Active Storage that lets an unauthenticated attacker read arbitrary files off the server through nothing more than an image upload. It carries a CVSSv4 score of 9.5, and researchers have already nicknamed it KindaRails2Shell for how directly it can escalate to remote code execution.
The root cause is a default Rails never should have shipped: Active Storage hands untrusted uploads straight to the libvips image-processing library without disabling libvips’ “unfuzzed” loaders — decoders that trust file headers more than they should. An attacker uploads a crafted image, triggers variant generation (the resize/crop step Active Storage runs automatically), and libvips reads whatever file path the payload points it to. Classified as CWE-1188, Initialization of a Resource with an Insecure Default, that’s arbitrary file read with zero authentication and zero user interaction beyond a normal upload flow.
Arbitrary file read on a Rails server isn’t a contained bug — it’s a master key. The process environment on most Rails deployments holds secret_key_base, database credentials, and API tokens for every connected service. Read the environment, and you can forge session cookies, decrypt encrypted columns, or pivot straight into whatever cloud storage and third-party APIs the app talks to. Rapid7 and HeroDevs both flag a realistic path from this file read to full RCE once secrets are in hand.
Affected versions: Rails 7.0.0 through 7.2.3.1, 8.0.0 through 8.0.5, and 8.1.0 through 8.1.3. If your app uses Active Storage with libvips as the image variant processor — the default for most Rails apps built since Rails 7 — you’re exposed.
What to do now: Upgrade immediately to Rails 7.2.3.2, 8.0.5.1, or 8.1.3.1 depending on your branch, and confirm your libvips install is 8.13 or newer — the patched Rails versions alone aren’t sufficient without a current libvips. After patching, rotate every secret the application process can read: secret_key_base, database passwords, and any API keys pulled from environment variables. Assume compromise before the patch existed, especially if your app accepts public image uploads without strict authentication in front of them.
Rails maintainers say full technical details will follow no later than August 28, giving teams a deliberate head start to patch before the complete exploit chain goes public. That window is the point — patch now, not when the write-up drops and turns this into a commodity exploit kit.