Rails fixed the file read on July 29. VulnCheck says the deserialization gadget it exposed still runs on a patched server for anyone holding the stolen key.
Ruby on Rails patched CVE-2026-66066 on July 29, 2026. On Monday, August 31, 2026, SecurityWeek reported that VulnCheck had observed threat actors exploiting it, saying attacks began the previous week — roughly the seven days from August 24 — about a month after the fix shipped. That is the new development. The vulnerability itself, the patch, and the exposure count are all from late July and early August.
The part that has not been widely reported is what the patch does not do. VulnCheck’s own analysis, published August 7, 2026, states that “while the fix blocks the libvips file read, it does not neutralize the variation-key Marshal deserialization: the RCE gadget still executes on a patched server given a valid signature.” An organization that upgraded Rails in early August and did nothing else is closed to the file read that steals the signing key, and still open to code execution by anyone who already has it.
What happened
The flaw, nicknamed KindaRails2Shell by its discoverer Ethiack, is in Active Storage’s handling of image variants. Rails’ advisory GHSA-xr9x-r78c-5hrm describes it in one sentence: “In its default configuration, a Rails application that displays image variants may allow an unauthenticated attacker to read arbitrary files from the server, including the process environment.”
The mechanism is a file-format trick. Rails’ own writeup explains that “HDF5’s External File List lets a dataset’s bytes live in another file named by path and offset, so rendering the ‘image’ reads an attacker-chosen file off the server and returns its contents as pixels.” An uploaded file that presents as an image to one parser and as an HDF5 dataset to another turns Rails’ thumbnailer into a file reader. What comes back is rendered as an image, and the attacker decodes the pixels.
Affected versions, from the Rails advisory: activestorage before 7.2.3.2, 8.0 through 8.0.5.0, and 8.1 through 8.1.3.0. Fixed in 7.2.3.2, 8.0.5.1, and 8.1.3.1. GitHub scored it CVSS v4.0 9.5 with the vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H — network reachable, no privileges, no user interaction, total confidentiality, integrity, and availability impact, and the same again on downstream systems.
The exploitation history has been contested from the start, and it is worth laying out in dates rather than in adjectives. Rapid7 published its analysis on July 30, 2026 and wrote: “As of July 30, 2026, Rapid7 is not aware of exploitation in the wild.” It added that “public code claiming to exploit CVE-2026-66066 exists, but it is unclear how closely it corresponds to the full attack chain reported privately to Rails.” On August 4, 2026, CISA’s automated SSVC assessment on the CVE record set exploitation to proof-of-concept, automatable to yes, and technical impact to total. On August 7, 2026, VulnCheck published its own exploit, a Docker target, packet captures, Suricata, Snort, YARA, and Sigma rules, and a count of “7,100+ exposed vulnerable instances of Ruby on Rails” — and said, in the same document, “No exploitation has been reported yet, but given the deployment footprint and public information, we would expect it to follow shortly.”
That August 7 document is the page SecurityWeek links to for the CVE in its August 31 story, and it still reads that way. The exploitation claim in that story is attributed to VulnCheck separately, by way of a LinkedIn post. VulnCheck’s published weekly initial-access report covering August 22 to August 28 — the week in which the attacks are said to have started — summarizes new exploits for DARKLANTERN, SPEAKINGSTONE, Windows Defender, Zimbra Collaboration, GeoServer, Flowise, and Langflow. It does not list Ruby on Rails or CVE-2026-66066.
Severity Daily could not reach the LinkedIn post. So the state of the evidence, stated plainly: exploitation is reported by a credible vendor through a social media post, relayed by a credible publication, and is not reflected in that vendor’s own dated exploitation record, in the CVE record, or in CISA’s Known Exploited Vulnerabilities catalog, which does not list CVE-2026-66066.
The CVE record is its own problem. NVD published CVE-2026-66066 on July 30, 2026 and last modified it on August 5, 2026. Its vulnStatus is still “Received” — NVD has not analyzed it. There is no NVD-assigned CVSS score. The only base score on the record is the 9.5 supplied by GitHub as a secondary source, plus CISA’s SSVC block. Thirty-two days after a critical, unauthenticated, network-reachable flaw in one of the most widely deployed web frameworks in production, the authoritative U.S. vulnerability record has not been touched by an analyst.
Why it matters
The gadget finding is the one that changes what teams have to do, and it is buried in a vendor research page rather than carried in the advisory. Rails’ fix stops the file read. It does not stop the second half of the chain, because the second half was never the bug — it is the framework working as designed. Active Storage signs variation keys and deserializes them; given a valid signature, it will keep doing that on a fully patched 8.1.3.1 server.
The practical consequence is that patch status and compromise status are decoupled here. If an application was exposed between late July and whenever it was upgraded, and an attacker read secret_key_base out of the process environment during that window, the upgrade does not evict them. They hold a key that signs anything the application will accept, on a server that reports itself as fixed. This is not a hypothetical corner of the vulnerability; it is the reason Rapid7’s guidance says to rotate “secret_key_base and other secrets accessible to the application process” as a distinct step from upgrading.
Credential rotation is the step organizations skip. It is disruptive, it touches sessions and signed cookies and anything else keyed off the same secret, and it does not show up as a missing patch on any scanner. A vulnerability management program that measures itself on version compliance will mark this closed and be wrong.
The exploitation reporting matters less than it appears to, and it is worth being clear about why. Whether attacks began on August 24 or have not begun at all does not change the action list. VulnCheck published a working exploit on August 7, along with detection rules, which means the exploit has been public and packaged for three weeks against a target set the same vendor measured at more than 7,100 internet-facing instances. The right posture does not wait for confirmation. But the reporting does matter for anyone whose escalation process requires evidence of active exploitation before they can take an outage window, and those teams deserve to know that the evidence is currently one social media post that the vendor’s own exploitation record does not corroborate.
The empty NVD record compounds it. A team triaging this from a feed keyed to NVD sees a critical CVE with no analyst-assigned score, no CPE configuration data to match against an asset inventory, and no KEV entry. Everything useful about this vulnerability — the affected version ranges, the workarounds, the gadget that survives the patch, the exposure count — lives in a GitHub advisory and two vendor blogs. That is the recurring shape of the problem this publication keeps finding: the record that everyone’s tooling reads is the record that says the least.
What to do
Upgrade to Rails 7.2.3.2, 8.0.5.1, or 8.1.3.1, and confirm libvips is 8.13 or later. If you cannot upgrade immediately, set the VIPS_BLOCK_UNTRUSTED environment variable with libvips 8.13 or later, or call Vips.block_untrusted(true) from an initializer with ruby-vips 2.2.1 or later. If your application pulls in ruby-vips only for image analysis rather than Active Storage variant processing, the advisory’s third option is to remove the dependency.
Then rotate secret_key_base and every other secret readable from the application process environment. Treat this as required, not optional, for any application that served image variants on a vulnerable version with untrusted uploads. Patching without rotating leaves the signature-gated code execution path intact.
Check whether it was ever exposed before you decide. The file read returns arbitrary paths as image bytes, so look for variant requests that produced unusually sized or malformed outputs, uploads whose declared type does not match their container, and any HDF5 signature in stored blobs. VulnCheck’s August 7 release includes Suricata, Snort, YARA, and Sigma rules and packet captures, which is the fastest way to get retroactive detection in place.
Sourcing note
Checked: the Rails GitHub Security Advisory GHSA-xr9x-r78c-5hrm for affected and fixed versions, the CVSS v4.0 vector, and the workarounds; the NVD API record for CVE-2026-66066 for its published and last-modified timestamps, its “Received” status, the absence of an NVD-assigned score, the CISA SSVC block dated August 4, 2026, and the absence of any cisaExploitAdd or cisaActionDue field; VulnCheck’s dated initial-access documentation for August 1 to 7, 2026 and for August 22 to 28, 2026; Rapid7’s July 30, 2026 analysis; SecurityWeek’s August 31, 2026 report.
Not reached: the VulnCheck LinkedIn post that is the stated source for the exploitation claim. cisa.gov returns 403 to automated fetching, so the KEV catalog was checked through the NVD record’s CISA fields rather than the catalog page itself; NVD lags the catalog by hours, so a very recent addition would not appear there.
Unresolved: whether exploitation of CVE-2026-66066 is occurring. One vendor says it began in the week of August 24; that vendor’s own published exploitation report for that week does not list it, and no CVE or catalog record reflects it. Also unresolved: why NVD has not analyzed a CVSS 9.5 record thirty-two days after publication.