漏洞概述Ruby on Rails“Rails”Web 应用程序框架近日曝出一个新的严重漏洞 CVE - 2026 - 66066它能让看似无害的图片成为窥探秘密的入口。该漏洞于 7 月 30 日披露严重程度评分高达 9.5 分满分 10 分对运行处理用户上传图片的 Rails 应用程序的企业构成重大威胁。此漏洞被称为“KindaRails2Shell”它利用了开源框架中过于轻信的 Active Storage 组件使未经验证的攻击者能够读取敏感文件甚至可能进行远程代码执行RCE。Active Storage 的 7.2.3.2、8.0.5.1 和 8.1.3.1 版本已修复该问题运行 Rails 的企业应立即更新。Beauceron Security 的 David Shipley 表示“攻击者上传的看似是图片实则是能窃取秘密的代码这才是最要命的。”攻击者获取关键权限Ruby on Rails 是一个开源的服务器端应用程序框架用于构建全栈 Web 应用程序和应用程序编程接口API。它因可扩展性强、易于学习和使用、支持快速应用开发、拥有超 1000 名工程师组成的活跃社区进行开发和维护以及近两百万行预构建代码的丰富库而受到开发者的欢迎。CVE - 2026 - 66066 专门针对 Rails 内置的 Active Storage 组件该组件允许用户将文件上传到云服务或本地磁盘并将其与应用程序关联。具体而言此漏洞利用了 Active Storage 与 libvips 图像处理库交互生成图像的方式。libvips 包含一些所谓的“未经过模糊测试”的操作这些操作未通过模糊测试技术来抵御恶意输入模糊测试可检测它们在何处崩溃、泄露数据或以其他异常方式运行。这使得它们在处理不可信内容时不安全但 Active Storage 并未充分禁用这些操作。SOCRadar 的首席信息安全官 Ensar Seker 解释道“CVE - 2026 - 66066 特别危险因为攻击者可能无需账户或特权访问权限。”攻击者可以通过上传特制文件来利用这个不安全的管道诱使 Active Storage 让他们访问 Rails 进程有权限访问的文件甚至是应用程序处理环境中的高度敏感文件。Seker 解释说实际上这可能会暴露环境变量、Rails 应用程序密钥、数据库凭证、云访问密钥、API 令牌以及连接服务的凭证。攻击者还可以获取用于对 cookie、凭证和会话数据进行签名和加密的 secret_key_base。一旦 secret_key_base 被泄露攻击者实际上就掌握了应用程序的关键权限。Seker 说“直接的漏洞是任意文件读取问题但窃取 Rails 的 secret_key_base 等秘密可能会将信息泄露问题演变成更广泛的安全漏洞。”根据应用程序的不同攻击者可能会伪造可信的应用程序数据或会话访问数据库和云服务横向渗透到连接的系统或者实现远程代码执行。Seker 表示这种攻击升级路径正是该漏洞被认定为严重漏洞的原因。“看似常规的图像上传功能如个人资料图片、头像或缩略图生成器可能会成为进入应用程序底层基础设施的入口。”如何判断是否受影响当应用程序配置为使用 libvips 进行 Active Storage 图像处理自 Rails 7.0 起为默认行为并且接受来自不可信或未经验证用户的图像上传时就会受到影响。Seker 建议企业审核每个内部和第三方应用程序以确定它们是否如此配置并立即对 Rails 和 Active Storage 进行补丁修复。他们还应该检查每个接受图像的功能包括头像、支持附件、产品图片和管理上传功能。他说仅升级 Rails 是不够的如果其底层仍安装有较旧版本的 libvipslibvips 必须是 8.13 或更高版本。Seker 指出Rails 项目提供的取证指南和工具可以帮助企业确定应用程序是否易受攻击或文件是否可被利用。此外审查应用程序、代理、对象存储和图像处理日志以查找可疑的上传或异常请求也很重要。管理员还应轮换 Rails 中的 secret_key_base 和其他所有凭证使活跃会话失效并调查下游系统中可能暴露的凭证。Seker 说“安全团队应将此视为潜在的秘密泄露事件而不仅仅是一次补丁管理操作。”不要轻信图像处理管道Seker 指出复杂的图像库支持多种格式依赖众多解析器和第三方组件从而形成了广泛的攻击面。因此这些库“应被视为不可信的代码执行区域”。他建议将图像处理隔离在专用的沙箱、容器中或者限制在对文件系统访问权限最小的工作进程中。不应有不必要的网络连接也不应允许访问应用程序的文件或秘密。应应用严格的白名单对文件内容进行人工验证并在处理上传文件之前进行扫描将其存储在应用程序目录之外。Seker 表示其他额外的控制措施应包括使用短期且范围狭窄的凭证、限制出站网络访问、监控依赖项和软件组成以及进行自动化测试以确认升级后禁用了危险的编解码器或操作。他指出“更广泛的教训是组织不能仅仅通过询问是否‘使用 Rails’来评估风险。”他指出运行相同 Rails 版本的两个应用程序根据其图像处理器、上传路径和操作系统包的不同可能面临截然不同的风险。这使得了解运行时配置、库和应用程序功能变得至关重要。他补充说此事件也证明了在漏洞响应中轮换密钥的重要性。“当漏洞允许任意文件访问时安装补丁可以关闭入口但无法撤销可能已被复制的凭证。”不要以为自己高枕无忧Beauceron 的 Shipley 指出此漏洞凸显了软件物料清单SBOM的完美用例它可以加速发现易受攻击的软件并进行分类处理。企业除了隔离系统和打补丁之外还可以采用智能 Web 应用程序防火墙进行监控和干预。他说“在任何严重漏洞事件中你最不想听到的就是‘任意代码执行’和‘远程代码执行’这两者都可能意味着坏消息。”他还指出有趣的是此次漏洞披露过程被打乱了。由于几位研究人员逆向工程了攻击方法并发布了概念验证代码Rails 比原计划提前近一个月发布了有关该漏洞的技术细节以及评估应用程序漏洞和查找数据泄露证据的取证工具。Seker 指出概念验证代码的出现“大大增加了机会主义扫描和攻击尝试的可能性”。因此他说“即使那些没有发现明显被攻击迹象的组织也不应认为仅靠打补丁就能消除之前泄露的秘密所带来的风险。”分类漏洞、安全、开发工具、软件开发、Web 开发、开发方法