2026-07-31 · view entry permalink →
CVE-2026-66066, Ruby on Rails Active Storage: an unauthenticated image upload reaches arbitrary file read through libvips' unfuzzed loaders, exposing every application secret (CVSS 4.0 9.5)
The Rails security team disclosed CVE-2026-66066 on 2026-07-29, nicknamed "KindaRails2Shell" by its finders, and CERT-FR carried it the following day (CERT-FR, 2026-07-30). The defect is one of insecure defaults rather than a memory-safety bug. libvips reads and writes image formats through loaders and savers, some of which it explicitly flags "unfuzzed", meaning the project does not consider them safe against attacker-controlled input. Active Storage, which has used libvips as its default variant processor since Rails 7.0, never disabled those operations before handing it user-supplied files. A crafted upload therefore reaches an unfuzzed loader and yields arbitrary file read in the context of the application process (Ruby on Rails security advisory, 2026-07-29).
The precondition set is narrower than "runs Rails" but wider than most operators will assume. The advisory states an application is affected if it uses libvips for Active Storage image processing (the default that load_defaults 7.0 set and that no later default has changed) and accepts image uploads from untrusted users, and it says in as many words that generating a variant is not a separate requirement. Authentication elsewhere in the application does not help, because the exposure sits in the image-processing pipeline rather than the request-authorisation layer. Ethiack notes one further precondition it is not detailing yet (that the libvips build be linked against certain third-party libraries) so not every deployment on a vulnerable version is equally reachable, and it states that applications configured for the alternative ImageMagick processor are outside this vector entirely (Ethiack, 2026-07-29).
The "possible remote code execution" in the CVE's title is a consequence rather than a direct primitive: file read as the application process exposes secret_key_base, the master key and everything credentials.yml.enc decrypts, storage and database credentials and third-party tokens, and those in turn open paths to code execution or to connected systems (Rapid7, 2026-07-30). That is why remediation does not end at the upgrade; Rapid7 advises rotating secret_key_base and every credential the process can reach on any application believed exposed, while noting that rotating it invalidates active sessions, signed and encrypted cookies, signed global IDs and existing Active Storage URLs.
Fixed releases are activestorage 7.2.3.2, 8.0.5.1 and 8.1.3.1, and the advisory is unusually blunt that the gem upgrade alone is not the fix: libvips itself must be at 8.13 or newer, because earlier versions cannot disable unfuzzed operations at all, and patched Active Storage raises an exception at boot rather than running in a configuration it cannot secure. Separately, Ethiack assesses that Rails versions 6.0.0 through 6.1.7.10 may be affected where Active Storage has been configured for libvips against its own defaults, with no fixed 6.x release available, a point Rapid7 relays with attribution to Ethiack, and which does not appear in the Rails advisory's own affected-version ranges.
No in-the-wild exploitation was reported as of 2026-07-30, and both reporting teams (Ethiack and GMO Flatt Security, who found it independently) are withholding proof-of-concept code and the full chain until no later than 2026-08-28. That is not the same as nothing public existing: Rapid7 records that public code claiming to exploit the flaw exists, while stating it is unclear how closely that code corresponds to the full attack chain reported privately to Rails (Rapid7, 2026-07-30). Ethiack's own framing is the reason this belongs in an out-of-cycle patch conversation rather than a monthly one: it tells operators to assume attackers with AI tooling can reconstruct the chain quickly once the patch diffs are public.
Detection is thin by design here, because a successful read looks like an ordinary upload. The realistic signals are on either side of the processing step: image uploads that fail or crash variant processing at anomalous rates, worker processes reading files well outside the storage tree (application configuration, environment files, key material) and any subsequent use of application secrets from a network location that has never presented them before. The last of these is the one worth instrumenting, since the value of this bug to an attacker is the credential, not the read. Verification is straightforward and worth doing before any of that: check the configured variant processor, the installed gem version against the three fixed points, and the system libvips version against the 8.13 floor.
An application is affected if it meets all of these requirements: Uses libvips for Active Storage image processing. This is config.active_storage.variant_processor = :vips, which load_defaults 7.0 set and no later default has changed. Allows image uploads from untrusted users. Generating variants is not a separate requirement.
Earlier versions of libvips (< 8.13) cannot disable unfuzzed operations at all, and Active Storage will raise an exception during boot in such an unsecurable environment.
No PoC or technical chain details from us yet, but assume attackers with AI tooling can reconstruct one quickly once patches ship and diffs go public, so don't wait to upgrade.
we held back details about the attack vector to allow applications to be upgraded before malicious attackers could take advantage of the vulnerability.
We originally intended to publish these details no later than 2026-08-28, but several researchers quickly reverse-engineered the attack and have already published proofs-of-concept.
As of July 30, 2026, Rapid7 is not aware of exploitation in the wild.
We reproduced the published chain against Rails 6.0.6.1, 6.1.7.10, 7.2.3.1, 8.0.5, and 8.1.3, and confirmed that patched 7.2.3.2, 8.0.5.1, and 8.1.3.1 targets block the crafted representation.
This RCE path does not depend on a Marshal object gadget. We validated it against Rails 8.0.5 configured with config.active_support.message_serializer = :json.
The disclosure timetable this entry's predecessor described has collapsed. Rails shipped the CVE-2026-66066 fixes on 2026-07-29 while deliberately withholding the exploitation mechanics (the security team "held back details about the attack vector to allow applications to be upgraded before malicious attackers could take advantage of the vulnerability") and intended to publish them no later than 2026-08-28. On 2026-07-31 it abandoned that plan, stating that "several researchers quickly reverse-engineered the attack and have already published proofs-of-concept" (Ruby on Rails security team, 2026-07-31). The four-week grace period the prior coverage described as the defender's buffer no longer exists.
Rather than publish prose alone, the team released a repository (rails/rails-forensics-CVE-2026-66066) containing four things a responder can use directly: a step-by-step walkthrough of the attack from the incoming request to the file being read, a guide to what evidence the attack leaves in the application database and object store, and, explicitly, what that evidence does and does not prove; plus two artifacts the team calls "agent skill"s rather than scripts, one that "works out whether your application was ever vulnerable, and if it was, over what period of time" and one that "searches your Active Storage data for the crafted files, and works out what was read if it finds any" (Ruby on Rails security team, 2026-07-31). The distinction matters operationally: these are skills intended to be driven by an AI coding agent, not standalone command-line tools. The post's author, writing as a member of the Rails security team, states the material was "extracted from work I did at 37signals to perform a forensic analysis on our own apps", that is, it comes out of one company's real incident response rather than being written for the advisory. Nothing about the vulnerable versions or the preconditions changed: activestorage below 7.2.3.2, 8.0.5.1 and 8.1.3.1 remain affected where the application uses the libvips variant processor and accepts image uploads from untrusted users, and the fix is only effective on libvips 8.13 or newer (Ruby on Rails GHSA, 2026-07-29).
One in-window operational signal accompanies the announcement, and it should be read carefully. A maintainer of the Discourse forum platform replied in the same thread on 2026-08-01 that Discourse has "noticed an increase in this style of attack" and described the defence-in-depth work it shipped that week, moving image processing out of high-privilege processes using Linux Landlock sandboxing, with the stated design goal that an image-resizing process should be able to write to one location rather than hold write access to the whole filesystem (Discourse maintainer reply on Ruby on Rails Discussions, 2026-08-01). That observation is about the class of attack against image-processing libraries, not about CVE-2026-66066 specifically; the same reply states Discourse currently uses ImageMagick with an allowed-coder list and is only now porting to libvips, so it is not describing exploitation of this Rails flaw (Discourse maintainer reply on Ruby on Rails Discussions, 2026-08-01).
The earlier entry recorded that Rails abandoned its embargo on the Active Storage attack chain four weeks early because researchers had already reconstructed it, and shipped forensic tooling so operators could determine whether they had been exploited. The delta is that the chain is now automated and packaged, and that the code-execution half has been validated more broadly than the original disclosure showed (Rapid7, 2026-08-03).
Rapid7 states it "reproduced the published chain against Rails 6.0.6.1, 6.1.7.10, 7.2.3.1, 8.0.5, and 8.1.3, and confirmed that patched 7.2.3.2, 8.0.5.1, and 8.1.3.1 targets block the crafted representation", which is a useful independent confirmation that the vendor's fixed versions actually close it. Its Metasploit module "creates crafted direct-upload blobs, confirms the file read against /proc/version, recovers and validates Rails signing material, signs an ImageProcessing variation, and triggers either send/spawn for command payloads or send/eval for native Ruby payloads." The mechanically important finding for anyone who assumed a safer serializer contained this: "This RCE path does not depend on a Marshal object gadget. We validated it against Rails 8.0.5 configured with config.active_support.message_serializer = :json." Applications that moved off Marshal serialization are not insulated.
One correction is worth stating plainly, because it would be easy to record this as an exploitation-status change and it is not one. Rapid7's emergent-threat tracker says "As of July 30, 2026, Rapid7 is not aware of exploitation in the wild", and neither of its posts claims observed scanning, honeypot activity or intrusions (Rapid7, 2026-07-30). What changed is the cost of exploitation, not evidence of it: the chain went from reconstructable-by-a-researcher to a module anyone can run, against a flaw that needs no authentication and no user interaction.
Detection, telemetry class first. Application and web access logs carry the sequence: a direct-upload blob creation followed within the same session by a variant or representation request for that same blob, where the declared content type claims an image. The file-read primitive surfaces as image processing reaching paths that are not user content, a request whose rendered output derives from a system path rather than an uploaded asset is the anomaly, and Rapid7's own proof-of-concept methodology uses exactly such a read as its confirmation step. Triage: ordinary Rails applications create blobs and request variants constantly, so neither event is meaningful alone; the discriminator is a variant request whose processing touches a path outside the application's own storage tree, and the tight upload-then-immediately-transform pairing within one session.