2026年7月29日周三晚间，Rietta（里埃塔）为受ActiveStorage严重远程代码执行漏洞影响的全部客户站点执行了紧急热修复程序，该组件属于Ruby on Rails 8及更新版本。我们基于同日补丁发布时同步公开的GitHub安全公告开展工作，发现该漏洞的研究团队之一Ethiack将其命名为KindaRails2Shell（CVE-2026-66066），初始披露发布于7月29日，完整技术深度解析则于次日7月30日发布。

2026年7月29日周三深夜，Rietta针对Ruby on Rails 8及更新版本中ActiveStorage组件的一个严重远程代码执行漏洞，对整个客户群的受影响站点执行了紧急热修复程序。我们依据当天补丁发布时同步公开的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变体处理中可能的任意文件读取和远程代码执行》公告的当天应用的。过程本身很直接：团队为每个受影响的Rails应用准备拉取请求，运行bundle update activestorage rails命令以获取最新的补丁版本，然后在本地和持续集成（CI）环境中运行全套自动化测试套件。只有当测试套件全部通过、确认没有其他问题时，我们才部署到生产环境。

我们通过电子邮件通知了每个受影响的客户，工作于美国东部时间晚上11:30左右结束。

细节禁运已被事态发展超越

安全公告保留了技术攻击链的叙述，承诺“不晚于”2026年8月28日全面披露。但实际上，从补丁发布的那一刻起，禁运就基本失去意义了——并非有人违反禁运，而是修复本身的公开代码差异从未被禁运，仅保留了利用方法的解释。而这个解释甚至没撑到一个月。Rails项目在次日（7月30日美国东部时间下午6:25）就在GitHub上发布了带有技术细节的取证工具。Ethiack在第二天早上（7月31日美国东部时间上午6:56）发布了完整的技术解析。两者都比GitHub公告最初声明的禁运日期提前了约四周。Rapid7的独立事件追踪也证实了原因：由于几位研究人员已经反向工程出攻击方法并发布了概念验证代码，Rails提前发布了取证工具，禁运无论Rails还是原始研究人员意愿如何都已被打破。

针对我们客户的首次攻击发生在这所有公开内容之前。攻击发生在美国东部时间7月30日早上7:10:25，距离我们打完补丁仅8小时1分钟，比Rails发布取证工具早11小时，比Ethiack的解析文章早近一整天。我们最初以为构造该载荷的攻击者是在补丁发布后几小时内自行通过补丁差异分析完成的。但新证据指向了更简单的原因：一个公开的概念验证漏洞在7月29日UTC时间晚上9:47:30被提交到GitHub，这比我们完成补丁部署（美国东部时间7月30日11:09 PM / UTC时间7月30日凌晨3:09）早5小时以上，比针对我们客户的首次攻击尝试早13小时22分55秒。

仅凭时间无法证明攻击者使用了该特定PoC而非其他工具或自研工具。但该PoC是首个使用畸形BMP文件触发漏洞的公开概念验证，而针对我们客户的首次攻击同样使用了恶意构造的BMP文件。这是一种关联，而非因果证明，但按溯因推理，这是最符合现有证据的简单解释：很可能不是某个特别快或技术高超的攻击者独自突破了禁运，而是整个漏洞研究生态的节奏超过了协调披露的 timeline。我们自己的紧急补丁尚未完成时，该PoC就已公开。在我们还有机会弥补这个差距之前，禁运策略就已经失败了。

Ethiack的研究员、该漏洞的发现者之一André Baptista（@0xacb）在公开交流中直接点明了更广泛的动态：

“我们多次保留技术细节，只为给防御者争取更多时间，但事态发展太快了。”

Baptista正是为该CVE保留技术细节的研究人员之一，对此有着切身体会。

攻击尝试始于7月30日深夜

一位州政府客户在2026年7月30日美国东部时间早上7:10:25记录到了首次攻击尝试，攻击者使用恶意构造的Windows位图（BMP）文件，来源为RIPE网络上的一个IP地址，伪装成Windows 10上的Chrome 131.0.0。这次尝试是孤立的单次命中，并非持续活动的开端。日志显示此后几天内该客户未再受到任何攻击，这与早期PoC来源的探测相符，而非大规模扫描活动的开始。

持续且不断变化的探测浪潮始于8月3日美国东部时间凌晨1:01:05，使用的是伪装成PNG的文件，而非首次尝试中的BMP。从那时起，攻击尝试持续不断，来自全球各地的轮换IP地址，使用多种用户代理，包括伪装成Anthropic的Claude-SearchBot爬虫，以及一个异常直白的用户代理Mozilla/5.0 (CVE-2026-66066 security verification)，直接标明其探测的CVE编号，而非试图伪装，这些请求同样来自国际IP地址段。

虽然该州政府客户确实使用了安全评估服务，但无论是7月30日的孤立探测还是8月3日开始的持续活动，均不能归因于这些服务。这明显是未经授权的探测，且从8月3日起，针对这个高严重度漏洞的探测从未停止。

攻击尝试与探测贯穿2026年8月

整个8月，利用该漏洞的尝试每天都在发生，且多集中在夜间。我们有日志证明攻击框架不仅实现了自动化，还有适应迹象，例如当某些额外安全措施上线后，攻击尝试会转向不同的变体。至于这些活动的自动化程度及攻击者动机，我们目前不予公开评论。

时间线回顾

CVE-2026-66066披露、修补与攻击尝试时间线 | 日期与时间 | 事件 | | --- | --- | | 2026年7月21日 | 合法安全研究人员首次发现 | | 2026年7月22日 | 研究人员按负责任披露流程联系Ruby on Rails维护者 | | 2026年7月29日 | 发布关键ActiveStorage更新，分配披露信息与公共漏洞追踪编号 | | 2026年7月29日，美国东部时间下午5:47:30 | 公开概念验证漏洞提交至GitHub，早于我们完成补丁的时间 | | 2026年7月29日，深夜 | Rietta按紧急热修复程序为受影响客户打补丁 | | 2026年7月29日，美国东部时间晚上11:09 | Rietta为某州政府客户部署经测试的更新 | | 2026年7月30日，美国东部时间早上7:10 | 同一州政府应用的异常日志显示来自境外IP的首次攻击尝试，为孤立单次命中 | | 2026年7月30日，美国东部时间晚上8:51 | Ruby on Rails项目发布入侵检测工具 | | 2026年7月31日，美国东部时间早上6:56 | André Baptista在https://ethiack.com发布技术发现 | | 2026年8月3日，美国东部时间凌晨1:01:05 | 使用伪装PNG文件的持续探测开始，区别于7月30日的孤立尝试 |

这对处理敏感数据的Rails应用意味着什么

教训远不止这一个CVE。协调披露的时间线并不能为防御者换取宽限期。补丁发布的那一刻，修复本身的公开代码差异就对所有愿意阅读的人可见，无需等待通俗的解释。我们的日志证明，“补丁公开”到“有效攻击尝试”的间隔可以以小时计，而非数周，这与禁运日期无关。

这就是我们的紧急热修复程序独立于严重等级评分、初始厂商沟通或禁运日期存在的原因。我们依据修复本身而非解析文章来打补丁。对于处理受监管数据的客户——无论是受HIPAA管辖的健康记录还是承担公共信任与披露义务的州政府系统——这种差异正是聘请一家将“已修补”视为监控第一天而非事件终点的公司的全部意义所在。

如果我们遵循常规的“通知-等待”流程，该客户最早也要在恢复办公时间后的某个时点才能打上补丁，最早可能是上午中段，前提是能联系到有权批准变更的人员。首次攻击尝试发生在早上7:10，距离我们未等许可就完成补丁8小时1分钟。若按常规审批周期，这个窗口不是简单的延迟，而是整个营业前时段系统都处于未修补、被主动盯上的严重漏洞暴露状态，甚至无人意识到需要做出决策。

所有这些攻击尝试都在补丁设计的防护点上被干净地拦截。但这并不意味着无事发生。一个实时政府系统在一个月内遭受持续、自适应、多来源的探测，本身就是值得关注的情况。快速打补丁决定了这是一次事件还是无事故。“漏洞利用失败”是我们希望保持的结果，而非停止关注的原因。此后我们增加了更多加固措施：更严格的文件上传校验、对重复扫描尝试的自动拦截以及集中告警。

实用建议

对于所有不是我们客户的人，我有以下实用建议：

1. 默认将任何依赖项的独立安全更新视为紧急事项，无需等待CVSS评分。评分的分配往往滞后于实际风险，有时滞后数小时。只要厂商发布了专门的安全更新，就不要等评分来告诉你严重程度。
2. 检查你的Ruby on Rails应用是否使用ActiveStorage。如果是且团队尚未升级，请严肃对待这一威胁，立即打补丁并核查暴露情况。
3. 在数小时内修补严重漏洞。提前建立紧急变更审批权限，不要等到需要时再授权，避免修复因等待某人醒来批准而被阻塞。
4. 通过夜间任务运行针对生态系统的自动化安全扫描。对于Rails，这意味着使用bundler-audit（检测依赖项中的已知CVE）和Brakeman（针对Rails特定漏洞模式的静态分析）。经验表明，这些夜间扫描往往比GitHub的Dependabot更快标记问题，远胜于等待定期外部安全审计报告来告知早已暴露的问题。每日对标记内容进行分类。
5. 对于任何处理用户上传文件的代码路径，将其视为独立的威胁模型边界。通过魔数而非Content-Type头校验文件类型；加固图像或文档处理库的策略（例如ImageMagick的policy.xml，禁用不使用的编码器和委托）；尽可能在沙箱或以降权方式运行处理过程。这是本次事件的实际攻击面。
6. 部署Web应用防火墙（WAF）如Cloudflare或AWS WAF & Shield，监控并针对你的环境调优。基于签名的规则往往无法识别隐藏在畸形文件中的新型载荷。将WAF视为一层防御，而非全部计划。
7. 持续增加自动化测试，让你确信软件在修补前后都能正常工作。开始信任这套安全网，以便在压力下快速行动。
8. 确保部署异常监控，且技术团队定期审查。失败的请求和成功的请求同样重要。特别关注对不存在路径的POST和PUT请求，这是对抗性探测的强烈信号。当某个现象反复出现时，增加校验和自动反制措施，对于Rails，可使用rack-attack限制重复攻击者。
9. 确保应用仅响应定向到你特定域名的请求，而非仅路由到你的IP。云服务商会在客户间轮换IP地址，这是基本的安全卫生习惯，也能减少噪音。
10. 配置并保留WAF日志（尤其是拦截记录）和应用内部日志。确保应用记录认证成功与失败的情况并定期审查。

我知道这份清单看起来不少。这通常是我们会引导客户完成并直接代为处理的事项。但这一点太重要，不容忽视。请复制这份清单，使用它，分享给你的朋友。即便我们从未合作，我也希望你能更安全。

Rietta的Ruby on Rails专业经验

作为一家公司，Rietta长期作为Ruby on Rails开发机构运营，下设亚特兰大Ruby开发者分部。我们在安全敏感行业享有声誉，为基础设施中包含定制Ruby on Rails应用的客户提供服务。我们也是亚特兰大Ruby用户组的赞助方，这是一个历史悠久的Ruby开发者社区。

我个人自2006年研究生时期就开始使用Ruby编程语言，自2011年起专业从事Ruby on Rails开发。多年来，我参与、培训并咨询了Ruby on Rails开发与安全的各类事项。如有任何问题，请告知我。

社区讨论整体带有质疑和调侃氛围，多数人认为漏洞披露过程存在过度渲染，少数人借此强调 AI 辅助安全测试的实用性。

认为漏洞披露内容存在过度渲染，实际问题被夸大

• 有读者指出文中关于“不修补就会立即面临生存级风险”的表述过于戏剧化，认为只要不将未修补的部署留在线上，风险并非不可避免，同时调侃政府站点对下线敏感本质是怕损失收入（较多人） > 过度渲染了，只要你不把没打补丁的服务留在线上就不会被入侵，政府站点总怕下线丢收入罢了（@kazinator）

认为 AI 已能快速复现类似漏洞，安全测试效率大幅提升

• 有用户分享自己让 AI 针对自家应用模拟同类攻击，仅用三分钟就通过自有文件上传库复现了类似漏洞，认为当前 AI 辅助安全测试的能力已经超出预期（较多人） > 让 AI 对着我们的站点跑了一遍，三分钟就用我们自己的文件上传库复现了类似漏洞，这个时代真的太夸张了（@throwatdem12311）

认为文章冗长，信息密度低

• 有读者认为原文内容可以压缩到十分之一，核心只需要讲清“存在漏洞和补丁、已给客户打补丁、补丁发布八小时内就出现公开利用、Rails 团队不得不提前公开技术细节”这几个关键点即可（较多人） > 这篇文章完全可以缩到十分之一长，核心就是有漏洞出了补丁、我们给客户打了、补丁发布八小时就出现公开利用、Rails 团队只能提前公开细节（@tyre）

调侃文章由 AI 生成，内容质量存疑

• 有用户调侃这篇披露文章的文风很像 AI 生成的内容，对其原创性和专业性表示怀疑（较多人） > 写得不错啊，Claude（@jeremyjh）

吐槽网站移动端适配差，影响阅读体验

• 有 iOS 用户反馈该站点移动端布局异常，大横幅遮挡了大部分正文，只能看到两行文字，询问是否其他人也遇到同样问题（较多人） > 这个网站的移动端格式太怪了，我只能用 iOS 看到两行文字，剩下的都被大横幅挡住了，有人也遇到吗（@onemoresoop）

有价值的补充

• 有用户提出疑问，是否需要服务器上运行着 Matlab 才会触发这类漏洞，点出了漏洞触发条件的特殊性
• 有用户认为 DHH 应该把更多精力放回 Rails 本身，而不是分散到 Omarchy 这类项目上，侧面反映社区对 Rails 核心维护投入的关注