정부 레일즈 사이트, CVE 패치 불과 몇 시간 만에 해킹 시도

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.” 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 Timeline of CVE-2026-66066 disclosure, patching, and exploitation attempts Date & Time Event July 21, 2026 Initial discovery by legitimate security researchers July 22, 2026 Researchers get in touch with appropriate Ruby on Rails maintainers following a responsible disclosure procedure July 29, 2026 Critical ActiveStorage update released. Disclosure and public vulnerabi