A Rails Bug Lets Strangers Read Your Server's Secrets Through a Photo Upload
CVE-2026-66066 in Active Storage scores a 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 hand over 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 software framework that powers a huge chunk of the web (Shopify, GitHub and Basecamp all grew up on it), has shipped an emergency fix for a nasty 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 the server treating it as a picture, it reads back sensitive files from its own disk and hands them over in the response.
That is the whole attack. No stolen password. No malware. 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 does not need to keep exploiting the bug. They can log in as any user by forging session cookies. They can read the database directly. They can pull files straight out of cloud storage.
In plain terms: a single crafted image can turn into full ownership of the application.
Seasoned web developers will recognise the shape of this. It is a path traversal or local file read, dressed up in a modern coat. The Hacker News flagged the parallel to classic file-inclusion bugs, and the parallel holds. New framework, old wound.
Who is affected?
Any Rails application that uses Active Storage and has not yet applied the patch. That is a lot of software. Active Storage ships with Rails and gets switched on the moment a developer wants users to upload anything, which is 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 that was sitting on a vulnerable server should be treated as already leaked. That means generating a new secret_key_base, a new master key, new database passwords, and new cloud storage access keys.
Rolling those credentials is the annoying bit. Skipping it is worse.
What about ordinary users of these sites?
There is 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 will hear about it through the normal channels: a forced password reset, a breach notice, an email from the company.
The sensible habit, as ever, is a unique password per site and two-factor authentication switched on wherever it is offered. Neither will save you from a leaked database, but both limit the blast radius when one leaks.
