CVE 补丁发布后数小时内，政府铁路网站出现瘫痪

2026 年 7 月 29 日星期三下班后，Rietta 在整个客户群中针对受 ActiveStorage（Ruby on Rails 8 及更高版本的组件）中严重远程代码执行漏洞影响的站点执行了紧急修复程序。我们完成了最初的 GitHub 安全建议，并在补丁发布的当天发布。 Ethiack 是发现该缺陷的研究团队之一，在 7 月 29 日同一天的首次披露帖子中将其命名为 KindaRails2Shell (CVE-2026-66066)，并在第二天 7 月 30 日进行了全面的技术深入研究。当我们的团队在 29 日工作时间内首次审查此漏洞时，它没有显示指定的严重性，只是发布了 Ruby on Rails 更新，其利用详细信息根据标准禁运条款保留。但到了晚上，我们的团队发现它的 CVSS 分数已攀升至极其严重的 9.5/10。这已经是最糟糕的情况了，这意味着任何补丁的延迟都会带来迫在眉睫的妥协的生存风险。客户背景 我们的客户群包括 HIPAA 涵盖的实体和州政府机构，其中许多机构在其基础设施中拥有基于 Ruby on Rails 的自定义应用程序。这些实体在数据泄露情况下面临严重的监管和声誉损害，并且在面临严重威胁时不能容忍任何拖延。在工作时间内，我们的团队审查了发布的详细信息，发现尚未分配严重性，并最初将其分类为可以在正常维护窗口下进行的定期更新。到了晚上，我们团队的持续监控显示 CVSS 已攀升至 9.5/10，我们宣布紧急修复。这些补丁是在 Rails 安全团队在 Active Storage 变体处理中可能的任意文件读取和远程代码执行中宣布并发布该漏洞的同一天应用的。这个过程本身很简单。该团队为每个运行bundle update activestorage Rails 命令的受影响的Rails 应用程序准备了拉取请求，该命令获取最新的修补版本。然后，团队在本地运行并让持续集成 (CI) 运行完整的自动化测试套件。只有在完整的测试套件顺利通过并确认没有其他问题后，我们才会部署到生产环境。我们通过电子邮件向每位受影响的客户通报了这一行动，并在美国东部时间晚上 11:30 左右结束了我们的工作。细节禁运已被事件所取代该公告保留了技术攻击链的叙述，并承诺“不迟于”2026 年 8 月 28 日全面披露。实际上，从补丁发布的那一刻起，该禁运在功能上就毫无意义，而不是因为有人违反了它。修复本身是一个公共代码差异，根本没有被禁止，只是解释了如何利用它。这个解释甚至一个月都站不住脚。 Rails 项目于第二天（美国东部时间 7 月 30 日下午 6:25）在 GitHub 上发布了带有技术细节的取证工具。 Ethiack 于第二天早上（美国东部时间 7 月 31 日上午 6:56）发表了完整的技术文章。两者均比 GitHub Advisory 上最初规定的禁运日期提前了大约 4 周。 Rapid7 自己的事件跟踪独立地证实了原因：Rails 在计划日期之前发布了取证工具，特别是因为几位研究人员已经对攻击进行了逆向工程并发布了概念验证代码，因此无论 Rails 或原始研究人员更喜欢什么，禁令都会让步。针对我们客户的第一次攻击早于这一切。它于 7 月 30 日上午 7 点 10 分 25 日（美国东部时间）发生，即我们应用补丁后 8 小时 1 分钟，比 Rails 自己的取证工具公开早了 11 个多小时，比 Ethiack 自己的文章早了近一整天。我们最初假设构建第一个有效负载的人是独立完成的，在发布后的几个小时内自行对修复进行了补丁差异化。新的证据指出了一种不同的、更简单的解释。 UTC 时间 7 月 29 日晚上 9:47:30 向 GitHub 提交了公开的概念验证漏洞。这距离我们自己的补丁完全部署还有 5 个多小时（7 月 30 日美国东部时间晚上 11:09 / 世界标准时间凌晨 3:09），距离我们的客户第一次尝试攻击还有 13 小时 22 分 55 秒。仅凭时间并不能证明我们的攻击者使用了特定的 PoC，而不是其他东西或他们自己的工具。该漏洞的发现者之一 Ethiack 的 André Baptista (@0xacb) 在 X 上与我的公开交流中指出了一个细节。 GitHub PoC 是第一个使用格式错误的 BMP 文件触发漏洞的公开概念验证。针对我们客户的第一次攻击尝试也使用了恶意形成的 BMP。这是一种相关性，而不是因果关系的证明。不过，通过逻辑溯因，这是符合我们现有证据的最简单的解释。这可能不是一个特别快速或熟练的攻击者独自打破禁运。它看起来更像是漏洞研究生态系统作为一个整体超过了c