KindaRails2Shell: Rails Active Storage arbitrary file read

Summary

This memo synthesizes public reporting (primarily Rapid7 and the Rails security announcement as relayed by Rapid7) on CVE-2026-66066 (“KindaRails2Shell”): a critical unauthenticated arbitrary file read in Ruby on Rails Active Storage image processing when libvips is used, with a documented path to remote code execution via recovered signing material. Affected apps are those that use the Vips Active Storage variant processor and accept untrusted image uploads; Magick is not in this vector. Rapid7 stated it was not aware of in-the-wild exploitation as of 30 July 2026. Other items in this cluster (Microsoft Exchange CVE-2026-62913, WordPress, BlackBerry QNX) are unrelated products and are not part of this chain; the provided MSRC page has no technical content.

Attack vector

An unauthenticated attacker reaches the surface over HTTP(S) against a Rails app that (1) uses libvips for Active Storage image processing and (2) accepts image uploads from untrusted users. Generating variants is not a separate exposure requirement. Vips is the default Active Storage variant processor on Rails 7.0+ defaults; only Vips is affected (Ethiack, via Rapid7). The documented chain needs the Active Storage direct-upload route to be reachable. When Active Storage routes are mounted, that route is present by default even if the app UI does not use direct uploads. The attacker creates a blob via direct upload with a false image content type and obtains a genuine signed variation_key from any page that renders an Active Storage representation. The deployed libvips build must include the matload operation. Rapid7 reports ordinary server-side attachment does not satisfy this chain because Rails re-identifies the crafted file as MATLAB data before variant processing.

Exploit

Bug class is CWE-1188 (initialization of a resource with an insecure default): Active Storage did not disable libvips operations marked unfuzzed/untrusted before processing user files. In the published chain, a crafted file presents as a MATLAB level-5 file to libvips but as a MAT 7.3 HDF5 container to libmatio; HDF5’s External File List then reads bytes from an attacker-chosen path. Those bytes are rendered as image pixels and returned in the variant (arbitrary file read of paths readable by the Rails process). The file-read stage does not require secret_key_base or a forged variation key. Rapid7 also describes an RCE escalation that uses recovered Rails signing material to forge an ImageProcessing 1.x variation; that path does not require Marshal deserialization. Ethiack and GMO Flatt Security withheld PoC and the full private chain; public exploit-claiming code appeared after third-party reverse engineering, and Rapid7 Labs later published a root-cause write-up and a Metasploit module (3 August 2026). This memo does not independently reverse or reproduce the issue.

In the wild / novelty

Disclosure: Rails advisory 29 July 2026. Rapid7: no known exploitation in the wild as of 30 July 2026. Rails initially planned fuller technical disclosure by 28 August 2026, then published details and forensic tools on 31 July 2026 after researchers reverse-engineered the attack and published PoCs. That is public PoC / reverse-engineering after coordinated disclosure, not confirmed victim exploitation. No honeypot or named-victim exploitation is stated in these sources.

Risk

Blast radius is any reachable Rails process using Vips Active Storage on affected versions (Rails 7.0.0–7.2.3.1, 8.0.0–8.0.5, 8.1.0–8.1.3; Active Storage earlier than 7.2.3.2; Rapid7/Ethiack: 6.0.0–6.1.7.10 if Vips is configured non-default). Successful file read can expose secret_key_base, Rails master key and decrypted credentials, storage/DB credentials, and third-party tokens—enabling forged signed objects, session/cookie impact, and possible RCE in the app process plus access to connected systems. Failure mode is full compromise of the application identity, not just a single uploaded file.

Remediation

Upgrade Active Storage/Rails to 7.2.3.2, 8.0.5.1, or 8.1.3.1 (Rapid7/Rails). Also require libvips ≥ 8.13; Rails/Active Storage patches alone are insufficient with older libvips. If ruby-vips is installed, use ≥ 2.2.1; patched Rails refuse to start if ruby-vips/libvips are too old to apply the untrusted-operation block. No official fixes for branches before 7.2: migrate or workaround. Temporary: on libvips ≥ 8.13 set VIPS_BLOCK_UNTRUSTED, or with ruby-vips ≥ 2.2.1 call Vips.block_untrusted(true) in an initializer; below libvips 8.13 the stated workaround is remove the libvips dependency. Rotate secret_key_base and all secrets the process could read (master key, credentials, storage, DB, third-party keys); rotation expires sessions and breaks signed cookies, signed global IDs, and Active Storage URLs. Use Rails forensic tools promptly to check vulnerability and hunt crafted blobs (unattached-blob cleanup can destroy evidence). Rapid7 Exposure Command/InsightVM/Nexpose checks were expected in the 31 July content release.

CVE / identifiers

CVE-2026-66066; CWE-1188. Cluster also names CVE-2026-62913 (Exchange, no technical detail in the provided MSRC fetch), CVE-2026-40272 / ZDI-26-566 / ZDI-CAN-30346 (QNX, unrelated), CVE-2026-65640 (WordPress, unrelated).

Confidence

high — for CVE-2026-66066, Rapid7 and the Rails advisory (as summarized by Rapid7) agree on vector, chain stages, versions, and mitigations with high specificity. This is a synthesis of that public reporting, not independent lab work. Confidence that CVE-2026-62913 belongs in the same incident is low (no shared technical content).

Open questions

Technical details of CVE-2026-62913 are absent from the provided MSRC page, so Exchange attack/exploit cannot be assessed here. How closely early public PoCs match the privately reported full chain was initially unclear (Rapid7). Whether every Vips-enabled Rails 6.x deployment is practically reachable without direct-upload is only partially constrained (Rapid7: known chain needs direct-upload; server-side attach does not). No source in this set confirms exploitation in the wild after 30 July 2026. WordPress and QNX articles do not describe this Rails/libvips issue.

Sources