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. Baptista put the broader dynamic plainly: “We have been holding back technical details in multiple cases to give defenders more time, but things are happening too fast.” “We have been holding back technical details in multiple cases to give defenders more time, but things are happening too fast.” Baptista is one of the researchers who held back technical details on this very CVE, which gives him specific insight into this matter. Attack Attempts Started Overnight on July 30th One particular client, a State government entity, logged the initial attack attempt with a maliciously formed Windows bitmap (BMP) file on July 30, 2026, at 07:10:25 AM EST, from an IP address on the RIPE network, presenting as Chrome 131.0.0 on Windows 10. 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. The continuous, adapting wave of probing began separately, on August 3, 2026 at 1:01:05 AM EDT, using a disguised PNG file rather than the BMP from the first attempt. From that point on, the attempts continued on a rotating set of IP addresses around the world, using a variety of user agents, including a malformed spoof of Anthropic’s Claude-SearchBot crawler and an unusually candid user agent, Mozilla/5.0 (CVE-2026-66066 security verification), that openly named the CVE it was probing for rather than attempting to disguise itself, again from an international IP address range. While our State government client does employ security assessment services, none of these attempts, the isolated July 30th probe or the sustained campaign that began August 3rd, are attributable to those activities. This was clearly unauthorized and, from August 3rd onward, continual probing of this high-severity vulnerability. Attack Attempts and Probing Continued throughout August, 2026 The attempts to exploit this behavior continued throughout the month on a daily basis, often during overnight hours. We have log evidence of attack frameworks not only automating but some indication of adaptation, such as when certain additional security measures were put into place the attempts changed to follow different variants. The extent this was all automated or the motivation of the attackers, we are not commenting on publicly at this time. Timeline Recapped What This Means for Rails Applications Handling Sensitive Data The lesson here is bigger than this one CVE. A coordinated disclosure timeline doesn’t buy defenders a grace period. The moment a patch ships, the fix itself, a public code diff, is available to anyone willing to read it instead of waiting for a plain-English writeup. Our own logs prove the gap between “patch published” and “working exploit attempted” can be measured in hours, not weeks, regardless of what the embargo date says. That’s why our emergency hotfix procedure exists independent of severity scoring, initial vendor communication, or embargo dates. We patch on the fix, not on the writeup. For our clients handling regulated data, whether HIPAA-covered health records or state government systems bound by public trust and disclosure obligations, that difference is the entire point of retaining a firm that treats “patched” as day one of monitoring, not the end of the incident. Had we followed a standard notify-and-wait process, this client wouldn’t have had a working patch until sometime after business hours resumed, likely mid-morning at the earliest, once someone with authority was reachable to approve the change. The first exploitation attempt hit at 7:10 AM, eight hours and one minute after we patched without waiting for permission. Under a conventional approval cycle, that window wasn’t a delay, it was a live, unpatched, actively-targeted critical vulnerability sitting open through the client’s entire pre-business-hours period, with no one even aware yet that a decision needed to be made. All of these attempts failed cleanly, at the exact point our patch intended. That doesn’t mean nothing happened. A month of sustained, adapting, multi-actor probing against a live government system is its own story. Patching fast made the difference between an incident and a non-event. We’ve since added more hardening: tighter upload validation, automated blocking for repeat scanning attempts, and centralized alerting. “The exploit failed” is a result we want to keep being true, not a reason to stop paying attention. Practical Advice For all of you, especially those who are not our clients, I have some practical advice. Treat any dependency’s standalone security release as urgent by default, even before a CVSS score is assigned. Score assignment lags real risk, sometimes by many hours. If a vendor ships a dedicated security release at all, don’t wait for a number to tell you how critical it is. Check whether your Ruby on Rails application uses ActiveStorage. If so and your team hasn’t upgraded yet, take this threat very seriously, patch immediately and investigate your exposure. Patch severe vulnerabilities within hours. Have emergency change-approval authority established in advance, before you need it, so a fix isn’t blocked waiting for someone to wake up and grant permission. Run automated, ecosystem-specific security scanning on a nightly job. For Rails, that means tools like bundler-audit (known CVEs in your dependencies) and Brakeman (static analysis for Rails-specific vulnerability patterns). In our experience, these nightly scans have beaten GitHub’s own Dependabot to flagging an issue, and they blow away waiting on a periodic external security audit report to tell you what’s already been sitting exposed. Triage what they flag daily. For any code path that processes user-uploaded files, treat it as its own threat model boundary. Validate file type by magic bytes, not content-type headers; harden your image or document processing library’s policy (for example, ImageMagick’s policy.xml, disabling coders or delegates you don’t use); and sandbox or run that processing with reduced privileges where you can. This was the actual attack surface in this incident. Set up a web application firewall (WAF) such as Cloudflare or AWS WAF & Shield, monitor it, and tune it to your environment. Signature-based rules often miss a novel payload hidden inside a malformed file. Treat a WAF as one layer of defense, never the whole plan. Continuously add more and more automated testing to give you confidence that your software worked before and after such patching. Start to trust this safety net enough to move fast under pressure. Ensure you have exception monitoring in place and that your technical team reviews it regularly. Unsuccessful requests matter as much as successful ones. Pay specific attention to POST and PUT requests to paths that do not exist, a strong indicator of adversarial probing. When something recurs, add validation and automated countermeasures, for Rails, something like rack-attack to throttle repeat offenders. Ensure your application only responds to requests directed to your specific domain name, not just routed to your IP. Cloud providers rotate IP addresses among customers so this is just good hygiene and reduces noise. Configure and retain logs at your WAF, especially blocks, and within your application. Ensure your application logs both authentication successes and failures and review regularly. I know this list might seem like a lot. This is often what we walk our clients through and handle directly on their behalf. However, this is too important to ignore. Please copy this list, use it, share it with your friends. I want you to be more secure even if we never personally work together. Rietta’s Specific Ruby on Rails Expertise As a company, Rietta has long served as a Ruby on Rails development agency, through our Atlanta Ruby Developer division. We have a reputation as a long-time vendor for security-sensitive industries with custom Ruby on Rails applications in their infrastructure. We also are the sponsor of the Atlanta Ruby Users’ Group, a long-standing community of Ruby developers. Personally, I have been working with the Ruby programming language since graduate school in 2006, and professionally with Ruby on Rails since 2011. I have worked with, trained developers on, and consulted on all matters of Ruby on Rails development and security for a long time now. If you have any questions, let me know.