Critical flaw in Rails Active Storage let uploaded files read secrets

Ruby on Rails published a fix on 29 July 2026 for a critical vulnerability in Active Storage, the component that handles file uploads and image processing in Rails applications. The advisory GHSA-xr9x-r78c-5hrm has been assigned CVE-2026-66066 and scored at 9.5. An attacker without login can upload a crafted file and have files read from the server, among them the application secret secret_key_base, database passwords and credentials for cloud services. The fix sits in versions 7.2.3.2, 8.0.5.1 and 8.1.3.1. Applications are exposed when they use the libvips library to process images and accept uploads from users the organisation does not control.

What happens technically

Active Storage creates variants of uploaded images, meaning resized or cropped versions for display on the site. The image work itself is handed to an image library, and libvips is the library recent Rails versions use. libvips holds a set of operations marked as unsafe for untrusted content, and the library therefore has a switch for blocking them. The advisory describes how Active Storage did not disable those operations in the default configuration.

The attack follows from that. A file built for the purpose can make variant generation call one of the unsafe operations, and the result is the reading of files the application process itself can access. In an ordinary Rails application that means configuration and environment variables, meaning secret_key_base, the database connection string and keys for cloud services. Rails states that a temporary workaround exists for installations running libvips 8.13 or later, in the form of the VIPS_BLOCK_UNTRUSTED environment variable or a call to Vips.block_untrusted in an initializer. Older builds of libvips have no workaround and must be upgraded. The advisory is clear on a point that is easily forgotten in a busy week. The update does not protect secrets that may already have been taken, so they have to be replaced. Full technical details are announced for release by 28 August 2026.

What this means for you if you have a Rails application

If you have a web shop, a portal or a line of business application built in Rails, this case concerns you. There are more of those around than you might think. The feature being exploited is not exotic. It is the profile picture, the attachment in an application form or the receipt a customer uploads to a case. Berigo's assessment is that the heavy part here is not the upgrade, which is trivial, but the consequence of secrets possibly being gone. Rotating secret_key_base invalidates signed cookies and active sessions, and every logged in user notices at the same moment. That is something you plan, not something you improvise on a Friday afternoon.

The second question is who can actually tell you whether you are affected. Rails applications are often built by an agency or a single supplier, and the hosting may sit somewhere else again. Knowing which version is running is therefore not enough on its own. You also need to know who owns the key rotation, and who confirms that it has been done. If your organisation is covered by NIS2, this is supply chain security under Article 21 in its most tangible form. We would also point out that the date for full details starts a clock, since exploit code tends to follow shortly after the details are out.

Berigo recommends

• Map which Rails applications the organisation has, both built in house and delivered, and which versions they run.
• Upgrade Active Storage to 7.2.3.2, 8.0.5.1 or 8.1.3.1, and libvips to 8.13 or later.
• Rotate secret_key_base, master keys and every credential readable from the server, and expect users to sign in again.
• Apply the temporary block on unsafe operations where the upgrade has to wait, provided libvips is recent enough.
• Ask the supplier to confirm in writing that both the update and the key rotation are complete, with dates.