【文章标题】：Government Rails Site Hit Hours After CVE Patch 【文章标题】：政府Rails网站在CVE补丁发布数小时后遭攻击
【文章正文】： Government Rails Site Hit Hours After CVE Patch 政府Rails网站在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. 2026年7月29日周三晚间，Rietta对我们所有受影响的客户站点执行了紧急修复程序，这些站点受到Ruby on Rails 8及以上版本组件ActiveStorage中一个严重远程代码执行漏洞的影响。我们根据当天发布的GitHub安全公告开展工作。发现该漏洞的研究团队之一Ethiack在7月29日的首次披露中将其命名为KindaRails2Shell（CVE-2026-66066），并于次日7月30日发布了完整技术分析。
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. 当我们的团队在29日工作时间首次审查该漏洞时，它尚未分配严重等级，只是一个已发布的Ruby on Rails更新，其利用细节按标准保密条款暂未公开。但到了晚上，我们发现其CVSS评分已飙升至极其严重的9.5/10分。这几乎是最高危险级别，意味着任何补丁延迟都会立即面临被攻破的生存风险。
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. 我们的客户包括受HIPAA保护的机构和州政府机构，其中许多在其基础设施中运行基于Ruby on Rails的定制应用程序。这些实体在数据泄露情况下将面临重大监管和声誉损害，因此在面临严重威胁时不容任何延误。
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. 在工作时间，我们团队审查了发布的细节，当时尚未分配严重等级，初步将其归类为可在常规维护窗口进行的普通更新。到了晚上，我们团队的持续监控显示CVSS评分已升至9.5/10，随即宣布进入紧急修复状态。
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. 这些补丁在Rails安全团队公布漏洞的当天即被应用，该漏洞涉及Active Storage变体处理中可能存在的任意文件读取和远程代码执行。整个过程非常直接：团队为每个受影响的Rails应用准备拉取请求，运行bundle update activestorage rails命令获取最新修补版本，然后在本地运行并让持续集成（CI）执行完整的自动化测试套件。只有在全部测试通过且确认无其他破坏后，我们才部署到生产环境。
We notified each impacted client of the action via e-mail and concluded our work around 11:30 PM EST. 我们通过电子邮件通知每位受影响客户相关操作，并于美国东部时间晚上11:30左右完成工作。
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. 公告中保留了技术攻击链的说明，承诺”不晚于”2026年8月28日全面披露。实际上，从补丁发布的那一刻起，这个保密条款就失去了实际意义，而且并非因为有人违反。修复本身（公开的代码差异）从未被保密，只有漏洞利用方法的解释受到限制。而这个解释甚至没能维持一个月——Rails项目在次日（7月30日美国东部时间下午6:25）就在GitHub上发布了包含技术细节的取证工具，Ethiack则在第三天早晨（7月31日美国东部时间6:56）发布了完整技术分析，两者都比GitHub公告中原定的保密日期提前了约四周。Rapid7的事件追踪独立证实了原因：Rails提前发布取证工具是因为多名研究者已经逆向工程了攻击方式并发布了概念验证代码，因此无论Rails或原始研究者意愿如何，保密条款都已失效。
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. 针对我们客户的首次攻击早于所有这些事件。它发生在7月30日美国东部时间上午7:10:25，即我们应用补丁后8小时1分钟，比Rails自身取证工具公开早11个多小时，比Ethiack的分析报告早近一整天。我们最初认为首个攻击载荷的构建者是独立通过补丁差异分析在修复发布后几小时内完成的。新证据指向一个更简单的解释：7月29日UTC时间21:47:30已有公开的概念验证利用代码提交到GitHub——这比我们完全部署补丁（7月30日美国东部时间23:09/UTC时间3:09）早5个多小时，比首次攻击尝试早13小时22分55秒。
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. 仅时间线并不能证明攻击者使用了特定PoC而非其他工具。该漏洞发现者之一、Ethiack的André Baptista（@0xacb）在X上与我的公开交流中指出：那个GitHub PoC是首个公开使用畸形BMP文件触发漏洞的概念验证。而我们客户遭遇的首个攻击尝试同样使用了恶意构造的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 be 这属于相关性而非因果证明。但根据逻辑推理，这是最符合现有证据的简单解释。攻击者很可能并非特别迅速或技术高超…（原文截断）