The team behind Ruby on Rails, one of the most widely used frameworks for building custom web applications, has patched a critical flaw in Active Storage — the component that handles file uploads, including the everyday job of resizing a profile photo or product image. Tracked as CVE-2026-66066 and rated 9.5 out of 10 in severity, the bug lets an attacker with no account and no login read arbitrary files off the server simply by uploading a specially crafted image and letting the application process it.
The root cause sits in how Active Storage hands uploaded images to libvips, an image-processing library, to generate thumbnails and variants. Active Storage failed to disable a set of libvips loaders that were never meant to run on untrusted input, so a crafted file can trick the server into reading files it shouldn't — including the application's own environment variables, which commonly hold the Rails secret key, database passwords, cloud storage credentials, and third-party API tokens. Anyone who reads those secrets can potentially go further: forging sessions, reaching the database, or in some configurations running their own code on the server. The flaw affects Rails 7.0 through 8.1.3, and Rails 6.x installs that were explicitly configured to use libvips. It was reported independently by researchers at Ethiack and at GMO Flatt Security, and the Rails team has released fixed versions 7.2.3.2, 8.0.5.1, and 8.1.3.1, alongside an updated libvips requirement.
What this means for your business
This only matters if a developer built you a custom web application on Ruby on Rails — a customer portal, marketplace, booking system, or internal tool — rather than a hosted, off-the-shelf platform. Rails powers a large share of custom business software precisely because it lets small teams ship real applications quickly, so this is a common stack, not a niche one. If your app lets any user, customer, or staff member upload a photo or document, treat that feature as the one to ask about first.
Two calls to make this week. First, ask your developer or agency directly: "is our application on Rails, does it use Active Storage, and has it been updated to the patched version?" Second, and easy to miss — because the flaw can expose secrets rather than just crash something, patching alone doesn't undo any exposure that may already have happened. Once the application is updated, rotate the credentials it can read: the Rails secret key, database password, cloud storage keys, and any API tokens the app holds. If you don't manage hosting yourself, ask whoever does whether that rotation has already happened as part of the patch.