Rails CVE-2026-66066 sees first active exploitation

A critical Ruby on Rails flaw in Active Storage, CVE-2026-66066, has drawn its first reported in-the-wild probing about a month after the fix shipped on July 29. Hedge what that means: the activity is canary and honeypot traffic that VulnCheck says it began seeing overnight, not a confirmed mass-exploitation campaign, and the CVE is not on CISA's Known Exploited Vulnerabilities catalog as of this writing. The official class in the Rails advisory is unauthenticated arbitrary file read, with remote code execution possible only as an escalation after secrets leak, not a direct unauthenticated shell.

What the bug actually is

The advisory, GHSA-xr9x-r78c-5hrm, and the matching CVE record, title it "Possible arbitrary file read and remote code execution in Active Storage variant processing," and classify it as CWE-1188, an insecure default. It scores CVSS v4 9.5, and the vector's AT:P element is the tell: an app is exposed only if it uses libvips for Active Storage image processing (variant_processor = :vips, the default since load_defaults 7.0) and accepts image uploads from untrusted users. The read primitive comes from a content-type that disagrees with a file's magic bytes, which can steer libvips into its MATLAB Level 5 reader and through libmatio and HDF5, whose External File List then pulls arbitrary files off disk. The "remote code execution" in the title is what an attacker may reach after reading a secret like secret_key_base from the environment and abusing Rails' signed internals, so treat it as an escalation path, not the entry.

Who is exposed, and the version math

This is not every Rails app. You need the vips processor and untrusted uploads together; the ImageMagick path is not the issue here, per Rapid7. Affected builds are activestorage below 7.2.3.2, the 8.0 line below 8.0.5.1, and the 8.1 line below 8.1.3.1. Early in August, VulnCheck counted roughly 7,100 internet-exposed Rails instances and reported no wild use; the change now is overnight probing it attributes to a France-based IP with an Israel-hosted command-and-control, surfaced through SecurityWeek, Help Net Security and Beta News. Note the wording carefully: this is VulnCheck's own "New KEV" catalog language, not a CISA KEV listing, and anyone paraphrasing it as "CISA added Rails to KEV" is wrong.

The patch, and the part still argued over

Fixed versions are 7.2.3.2, 8.0.5.1 and 8.1.3.1, and the maintainers also recommend raising libvips to 8.13 or newer and ruby-vips to 2.2.1 or newer. If you cannot patch at once, set the VIPS_BLOCK_UNTRUSTED environment variable or call Vips.block_untrusted(true) from an initializer, and if your libvips predates 8.13, remove it. Rotate secrets after patching, because the file read may already have exposed them. The residual debate belongs in context, not in a panic: some researchers say that on 8.1.3.1 the libvips read is closed but a variation-key Marshal path can still run given a valid signature, while Rapid7 describes a forged ImageProcessing variation route that avoids Marshal. Both live in post-secret, valid-signature territory; neither makes the July patch useless. The chain was reported by researchers at Ethiack and GMO Flatt Security. Unlike the ownCloud, Linux and Artifactory bugs CISA did add to KEV, and unlike the PaperCut zero-day that forced an emergency patch, this one still sits on the vendor advisory alone.

The takeaway

Patch to a fixed activestorage, raise libvips to 8.13 or newer, or block untrusted input if you cannot move yet, and rotate secrets on the way out. If you accepted untrusted uploads while running a vulnerable build, do not stop at patching: run the Rails forensics toolkit for this CVE and assume the read primitive may have touched your keys before you did.