Government Rails Site Hit Hours After CVE Patch

After hours on Wednesday, July 29, 2026, Rietta executed our emergency hotfix procedure across our entire client base for sites impacted by a severe remote code execution vulnerability in ActiveStorage, a component of Ruby on Rails 8 and newer. We worked off the initial GitHub Security Advisory, published the same day the patch shipped. Ethiack, one of the research teams that discovered the flaw, dubbed it KindaRails2Shell (CVE-2026-66066) in their initial disclosure post that same day, July 29th, with a full technical deep-dive following the next day on July 30th. When our team first reviewed this vulnerability during business hours on the 29th, it showed no assigned severity, just a Ruby on Rails update released, its exploitation details withheld under the standard embargo terms. By evening, though, our team saw it had climbed to an extremely severe 9.5/10 CVSS score. That is about as bad as it gets and meant that any delay in patching was an existential risk of imminent compromise. Client Background Our client base includes HIPAA-covered entities and State government agencies, many of which have Ruby on Rails-based custom applications within their infrastructure. These are entities that face significant regulatory and reputational damage in a data breach scenario, and they can brook no delay when faced with a severe threat. During business hours, our team reviewed the released details, saw no severity yet assigned, and initially triaged it as a regular update that could proceed under normal maintenance windows. By evening, our team’s ongoing monitoring showed the CVSS had climbed to 9.5/10, and we declared a hotfix emergency. These patches were applied on the same day that the vulnerability was announced and published by the Rails security team at Possible arbitrary file read and remote code execution in Active Storage variant processing. The process itself was straightforward. The team prepared pull requests for each impacted Rails app that ran the bundle update activestorage rails command, which fetched the latest patched release. The team then locally ran and let continuous integration (CI) run the full automated test suite. Only once the full test suites passed cleanly, confirming nothing else had broken, we deployed to production. We notified each impacted client of the action via e-mail and concluded our work around 11:30 PM EST. The Detail Embargo Was Already Overtaken by Events The advisory withheld the technical attack-chain narrative, promising full disclosure “no later than” August 28, 2026. In practice, that embargo was functionally meaningless from the moment the patch shipped, and not because anyone breached it. The fix itself, a public code diff, was never embargoed at all, only the explanation of how to exploit it. That explanation didn’t even hold for a month. The Rails project published forensic tooling with technical detail the very next day, July 30th at 6:25 PM EST, on GitHub. Ethiack published its full technical write-up the following morning, July 31st at 6:56 AM EDT. Both arrived roughly four weeks ahead of the originally stated embargo date on the GitHub Advisory. Rapid7’s own incident tracking independently confirms why: Rails released the forensic tooling ahead of its planned date specifically because several researchers had already reverse-engineered the attack and published proof-of-concept code, so the embargo was giving way regardless of what Rails or the original researchers preferred. The first attack against our client predates all of that. It hit at 7:10:25 AM EST on July 30th, eight hours and one minute after we applied the patch, more than eleven hours before Rails’ own forensic tooling went public and nearly a full day before Ethiack’s own write-up. We initially assumed whoever built that first payload had done so independently, patch-diffing the fix themselves in the hours after it shipped. New evidence points to a different, simpler explanation. A public proof-of-concept exploit was committed to GitHub at 9:47:30 PM UTC on July 29th. That’s over 5 hours before our own patch was even fully deployed (11:09 PM EDT / 3:09 AM UTC on July 30th), and 13 hours, 22 minutes, and 55 seconds before the first attack attempt against our client. Timing alone doesn’t prove our attacker used that specific PoC rather than something else, or their own tooling. André Baptista of Ethiack (@0xacb), one of the vulnerability’s own discoverers, pointed out a detail in a public exchange with me on X. That GitHub PoC was the first public proof-of-concept to use a malformed BMP file to trigger the exploit. The first attack attempt against our client also used a maliciously formed BMP. That’s a correlation, not proof of causation. By logical abduction, though, it’s the simplest explanation that fits the evidence we have. This probably wasn’t one especially fast or skilled attacker beating the embargo alone. It looks more like the vulnerability research ecosystem as a whole outpacing the coordinated disclosure timeline. Our own emergency patch wasn’t even finished yet when that PoC went public. The embargo strategy failed before we had any chance to close that gap.

That first attempt was an isolated single hit, not the opening shot of sustained activity. The logs show nothing further against this client for several days afterward. That’s consistent with a probe sourced from the early PoC rather than the start of a broader scanning campaign.