A Rails Bug Lets Strangers Read Your Server's Secrets Through a Photo Upload
CVE-2026-66066 in Active Storage scores 9.5 out of 10 for severity, and no login is required to exploit it.
Key points
- Ruby on Rails has patched a critical flaw, tracked as CVE-2026-66066, that scored 9.5 out of 10 on the standard severity scale.
- The bug lives in Active Storage, the part of Rails that handles file uploads like profile pictures.
- An attacker does not need an account or a password to trigger it.
- A successful attack can expose database passwords, cloud storage keys, and the Rails master key that unlocks the app's other secrets.
- Any site running Rails should patch immediately and rotate the credentials that were sitting on disk.
Ruby on Rails, the framework that powers Shopify, GitHub and a good slice of the commercial web, has shipped an emergency fix for a serious one.
The flaw sits in Active Storage, the piece of Rails that handles file uploads. Think: the little box on a website where you drop in a profile photo or a receipt. That box, in vulnerable versions, can be tricked.
What can an attacker actually do?
Read files off the server without logging in. A hacker uploads a specially crafted image, and instead of treating it as a picture, the server reads back sensitive files from its own disk and hands them over in the response. No stolen password. No malware required. Just a booby-trapped upload.
The bug is tracked as CVE-2026-66066 and carries a severity score of 9.5 out of 10, which is about as loud as these ratings get.
Why is this so bad?
Because of what Rails apps typically keep on disk. The files an attacker can pull include the Rails process environment and the app's deepest secrets: secret_key_base (used to sign user sessions), the Rails master key (which decrypts every other secret), database passwords, and cloud storage credentials for services like Amazon S3.
Hand those over and an attacker doesn't need to keep exploiting the bug. Session cookies can be forged, the database read directly, files pulled straight out of cloud storage. A single crafted image can become full ownership of the application.
Seasoned web developers will recognise the shape of this. It's a path traversal, or local file read, dressed up in a modern coat. New framework, old wound. The pattern isn't unlike what we reported on 20 July in WP2Shell: Two WordPress Flaws Let Attackers Take Over Websites Without Logging In, where unauthenticated access again turned into full site compromise.
Who is affected?
Any Rails application using Active Storage that hasn't yet applied the patch. Active Storage ships with Rails and gets switched on the moment a developer wants users to upload anything, which covers most apps.
| Detail | Value |
|---|---|
| CVE ID | CVE-2026-66066 |
| Severity score | 9.5 / 10 |
| Affected component | Active Storage |
| Attacker needs login? | No |
| Worst-case impact | Full read of app secrets and credentials |
What should site owners do right now?
Patch, then rotate. Updating Rails closes the door, but any secret sitting on a vulnerable server should be treated as already leaked. That means generating a new secret_key_base, a fresh master key, new database passwords, and new cloud storage access keys. Rolling those credentials is the annoying bit. Skipping it is worse.
Should ordinary users of these sites worry?
There's nothing for a customer to install or click. If a site you use was running a vulnerable Rails app and gets breached because of this, you'll hear about it through normal channels: a forced password reset or a breach notice from the company.
A unique password per site and two-factor authentication won't save you from a leaked database, but both limit how far the damage travels when one leaks.
