Rails ActiveStorage CVE hit a state government site 8 hours after patch
On July 29, 2026, a severe remote-code-execution vulnerability was disclosed in ActiveStorage, a component of Ruby on Rails 8 and newer. Ethiack, one of the research teams that found the flaw, named it KindaRails2Shell (CVE-2026-66066) the same day, with a full technical write-up to follow. Security firm Rietta, whose clients include HIPAA-covered entities and state government agencies, first reviewed the release during business hours on the 29th and saw no severity score yet assigned, so it queued the update as a routine maintenance item. By evening the CVSS score had climbed to 9.5 out of 10, and Rietta declared an emergency hotfix, testing and deploying the patch across its affected client applications and finishing around 11:09 PM EDT that night.
Despite the same-day patch, one client, described only as a state government entity, logged an exploit attempt using a maliciously formed Windows bitmap (BMP) file at 7:10:25 AM EST on July 30, eight hours and one minute after Rietta had applied the fix. That was more than eleven hours before the Rails project published its own forensic tooling (July 30, 6:25 PM EST) and nearly a full day before Ethiack's complete technical write-up (July 31, 6:56 AM EDT). The attempt failed, and it was an isolated single hit rather than the start of sustained activity; Rietta's logs show nothing further against that client for several days afterward.
Rietta traces the timing to a public proof-of-concept exploit that was committed to GitHub at 9:47:30 PM UTC on July 29, over five hours before Rietta's own patch was even fully deployed (3:09 AM UTC on July 30) and 13 hours, 22 minutes, and 55 seconds before the attack attempt against its client. André Baptista of Ethiack, one of the vulnerability's own discoverers, told Rietta in a public exchange on X that this GitHub proof of concept was the first public one to use a malformed BMP file to trigger the exploit, the same file type used in the attack on Rietta's client. Rietta calls that a correlation rather than proof its attacker used that exact code, but says it is the simplest explanation fitting the evidence, and argues the pattern points less to one unusually fast attacker than to the vulnerability-research ecosystem as a whole outpacing the coordinated-disclosure timeline. Rapid7's own incident tracking is cited for a related point: that Rails moved its forensic-tooling release forward because several researchers had already reverse-engineered the flaw and published their own proof-of-concept code.
A second, sustained wave of probing began separately on August 3 at 1:01:05 AM EDT, using a disguised PNG file instead of the original BMP, and continued daily through the rest of the month from a rotating set of international IP addresses and a variety of user agents, including a spoofed version of Anthropic's Claude-SearchBot crawler and one that openly named the CVE it was scanning for. Rietta says its client does use authorized security assessment services but that none of the probing, from the isolated July 30 attempt through the sustained August campaign, is attributable to that authorized activity. Every attempt failed at the point the patch was designed to stop it; Rietta has since added tighter upload validation, automated blocking of repeat scanners, and centralized alerting for the client.
Key facts
- CVE-2026-66066 ("KindaRails2Shell"), a remote-code-execution flaw in Rails ActiveStorage, was disclosed on July 29, 2026, and its CVSS score climbed to 9.5/10 by that evening.
- Security firm Rietta patched its affected client applications the same day, finishing deployment around 11:09 PM EDT.
- A state government client was hit by an exploit attempt using a malformed BMP file at 7:10:25 AM EST on July 30, eight hours and one minute after Rietta's patch was applied, more than eleven hours before Rails published its own forensic tooling.
- A public proof-of-concept exploit was committed to GitHub at 9:47:30 PM UTC on July 29, over five hours before Rietta's patch finished deploying and 13 hours, 22 minutes, 55 seconds before the attack attempt; both the PoC and the attack used a malformed BMP file.
- A second, sustained wave of probing began August 3 using a disguised PNG file and continued daily through the month, from rotating international IPs; every attempt failed against the patched system.
Why it matters
Coordinated disclosure is built around an embargo that is supposed to give defenders a head start before attackers get the technical detail. This incident shows that grace period can be an illusion: the fix itself, a public code diff, is readable the moment a patch ships, independent of when a plain-language write-up, forensic tooling, or even a CVSS score follows. Rietta's logs put a concrete number on the gap: a working exploit attempt hit a live government system eight hours and one minute after the patch went out, and the public proof-of-concept behind it was posted before Rietta's own patch had even finished deploying.
Who it affects
Anyone running Ruby on Rails 8 or newer with ActiveStorage is exposed to CVE-2026-66066 directly. The account centers on organizations handling regulated or sensitive data, HIPAA-covered health entities and state government agencies among Rietta's own client base, where a breach carries added regulatory and reputational exposure. It is also a case study for any security team that waits on a CVSS score or an embargo date before treating a dependency's security release as urgent.
How to use it
Rietta's own practical advice: treat a dependency's standalone security release as urgent before a CVSS score is even assigned; check immediately whether your Rails application uses ActiveStorage and patch it if so; set up emergency change-approval authority in advance so a fix is not blocked waiting for someone to grant permission; run nightly automated scanning such as bundler-audit and Brakeman rather than waiting on periodic external audits; for any code path handling user-uploaded files, validate file type by magic bytes rather than content-type headers, harden image or document processing libraries, and sandbox that processing with reduced privileges; deploy and tune a web application firewall as one layer of defense, not the whole plan; and expand automated testing so a team can trust it enough to patch quickly under pressure.
How solid is it
This is a first-person account from Rietta, the firm that performed the patch and holds the underlying log data, so it doubles as an account of its own emergency-response service. Its central timeline is corroborated by outside markers: the Rails project's own forensic-tooling publication time, Ethiack's disclosure timeline, and Rapid7's independent incident tracking, cited for why Rails moved its tooling release forward. The specific claim that the attacker used that exact GitHub proof of concept is explicitly presented as a correlation, a shared use of a malformed BMP file, not confirmed causation. The identity of the government client, staffing details, and the total cost of the emergency response are not disclosed.
Risks and caveats
Rietta declines to say publicly how much of the month-long probing was automated or what motivated the attackers. The version of the post available for this story cuts off mid-sentence partway through the practical-advice list, so any further recommendations after monitoring exception logs are not available here. The account also comes from a vendor describing its own product working as intended, a framing worth weighing alongside the timeline it reports.
“We have been holding back technical details in multiple cases to give defenders more time, but things are happening too fast.”
— André Baptista, Ethiack, one of the vulnerability's discoverers, in a public exchange on X