Rails maintainers have patched a critical Active Storage vulnerability that can let an unauthenticated attacker turn image uploads into arbitrary file reads, potentially exposing the secrets a Rails application needs to run.
The flaw, tracked as CVE-2026-66066, affects Rails applications that use Active Storage variant processing with libvips and accept image uploads from untrusted users. The Rails advisory rates the issue critical with a CVSS v4 score of 9.5. Fixed releases are available for Active Storage 7.2, 8.0, and 8.1.
The immediate response is straightforward: upgrade affected Rails or Active Storage versions, make sure libvips is new enough, and treat any exposed application secrets as potentially compromised. The harder work is figuring out whether an application was vulnerable before the patch and whether an attacker used the bug to read anything sensitive.
Who Is Exposed
The vulnerable path requires more than simply running Rails. An application has to use Active Storage image processing through libvips and allow untrusted users to upload images, either through ordinary upload forms or direct uploads. That makes avatars, profile photos, attachments, thumbnails, user-submitted logos, marketplace listings, support-ticket screenshots, and similar features the first places to check.
The affected versions listed by Rails are Active Storage earlier than 7.2.3.2, 8.0.x earlier than 8.0.5.1, and 8.1.x earlier than 8.1.3.1. Rails 6.x is a narrower case: researchers at Ethiack wrote that normal Rails 6.x defaults are not exposed, but Rails 6 applications may be affected if Active Storage was configured outside those defaults and accepts untrusted image uploads.
ImageMagick users are not affected by this specific vector, according to the public reporting around the advisory. That does not make image processing low risk in general, but it matters for triage: teams need to identify the processor and system library actually used in production, not only the Rails version in a Gemfile.
Why Image Uploads Become a Server-File Problem
The Rails forensics repository published after the advisory gives a plain-English explanation of the chain. Rails can decide that an uploaded blob is eligible for image processing based on the Active Storage content type recorded for that blob. libvips then inspects the file bytes and may route the file into a lower-level loader.
In the documented attack path, a crafted file passes through a chain involving MATLAB and HDF5 parsing. HDF5 supports an External File List feature, where dataset bytes can be stored in another file named by path and offset. When the crafted file is processed as an image variant, the server can be made to read an attacker-chosen file and return its contents as pixel data.
That distinction is important operationally. The first confirmed impact is arbitrary file read as the user running the Rails process or worker. But the files most worth stealing from a Rails server are often credentials: environment variables, secret_key_base, Rails credentials, database passwords, cloud-storage keys, API tokens, and other material that lets an attacker sign, impersonate, or move into connected systems.
Rapid7 reported that, as of July 30, it was not aware of exploitation in the wild, while also noting that public code claiming to exploit the bug had appeared and that the privately reported chain had RCE potential. Rails originally planned to withhold full technical details until August 28, but the team published attack details and investigation tooling early after researchers quickly reverse-engineered the issue and released proofs of concept.
Patch Rails, Then Check libvips
The fixed Rails releases are 7.2.3.2, 8.0.5.1, and 8.1.3.1. Teams should upgrade to the appropriate release or later and confirm that the deployed application is actually running the patched Active Storage code in every environment that accepts uploads or processes variants.
Rails also warns that the fix depends on libvips 8.13 or later. If libvips is older than 8.13, there is no real workaround other than removing the libvips dependency from the application. Some applications declare ruby-vips only for image analysis or include it even when Active Storage is not used; those cases may be able to remove the dependency entirely.
For applications already on libvips 8.13 or later, a temporary mitigation is available by setting the VIPS_BLOCK_UNTRUSTED environment variable. Applications using ruby-vips 2.2.1 or later can instead call Vips.block_untrusted(true) from an initializer. Those mitigations are stopgaps, not substitutes for moving to a fixed Rails release.
Secret Rotation Is Part of the Fix
Because the bug can expose files readable by the Rails process, patching is only the first half of the incident response. Rails recommends rotating secret_key_base, the Rails master key, database credentials, Active Storage service credentials, and other secrets available to the application process.
That work can be disruptive. Rotating secret_key_base can invalidate signed cookies and other signed application data. Changing database and cloud-storage credentials may require coordinated deploys across web workers, background jobs, console access, and any separate services that share the same credentials. Still, leaving stolen secrets valid after patching gives an attacker a path that no longer depends on the image-processing flaw.
Security teams should also review whether production image workers run with broader filesystem, network, or credential access than they actually need. The public Discourse thread on the Rails announcement included a defense-in-depth discussion from Discourse co-founder Sam Saffron about isolating image-processing work with mechanisms such as resource limits, network restrictions, seccomp profiles, and Linux Landlock. The practical lesson is that thumbnail generation should not have the same reach as the full application when a narrower process can do the job.
Use the Forensics Tooling Carefully
Rails published a dedicated forensics repository for two questions: whether an application was vulnerable and whether the attack appears to have been used. The repository includes documentation, scanner code, and agent-readable skills that examine Active Storage data for crafted files and try to determine what may have been read.
The tooling is intentionally scoped. It covers Active Storage applications using the :vips variant processor where variant records were tracked. It does not prove that every possible upload path is safe, and it does not cover other libraries or custom image-processing systems that pass user-supplied files to libvips outside Active Storage.
That makes the investigation a sequence rather than a single yes-or-no command. Inventory the application versions, processor settings, direct-upload behavior, object-store locations, and variant-record configuration. Then check for suspicious crafted uploads and rendered variants that may contain stolen bytes. A clean result from the Rails tooling is useful evidence, but not a reason to skip credential rotation if the application was clearly exposed and handled sensitive secrets.
What Teams Should Do Now
Rails teams should start with four concrete checks. First, identify every application that uses Active Storage and accepts user-controlled image uploads. Second, confirm whether production uses libvips, including through official Rails Docker images, Debian or Ubuntu packages, and deployment images that may differ from local development.
Third, upgrade to Active Storage 7.2.3.2, 8.0.5.1, 8.1.3.1, or later, and verify libvips is at least 8.13 if it remains installed. Fourth, rotate secrets that the Rails process could read, beginning with signing material and credentials that open access to databases, object stores, payment systems, admin APIs, email providers, and other connected services.
For larger environments, add two follow-up tasks: preserve upload and object-store evidence before aggressive cleanup, and move image processing toward a narrower permission model. CVE-2026-66066 is a Rails vulnerability, but the durable lesson is wider than Rails. Any web application that turns hostile user files into server-side thumbnails is running parser code on attacker-supplied input. That code should be patched quickly, watched closely, and given less power than the main application.
