一个Ruby on Rails（以下简称"Rails"）Web应用框架中的高危漏洞CVE-2026-66066，可能让一张看似无害的图片成为攻击者窃取敏感信息的突破口。
该漏洞于7月30日披露，CVSS评分高达9.5分，对所有在Rails中处理用户上传图片的企业应用构成重大威胁。
该漏洞被命名为"KindaRails2Shell"，攻击目标是Rails开源框架中的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名工程师组成的活跃社区，以及近200万行预构建代码的庞大代码库。
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是不够的，若底层libvips版本过旧，同样存在风险——libvips必须升级至8.13或更高版本。
Rails项目提供的取证指南和工具可帮助企业判断应用是否存在漏洞，以及文件是否可被利用，同时也有助于排查数据泄露的痕迹。此外，还应检查应用日志、代理日志、对象存储日志及图像处理日志，重点关注可疑上传或异常请求。
管理员还应轮换secret_key_base及Rails中所有其他凭据，使当前活跃会话失效，并对下游系统展开调查，排查潜在的凭据泄露风险。
Seker表示："安全团队应将此次事件视为潜在的机密泄露事故，而非单纯的补丁管理工作。"
他还指出，复杂的图像处理库支持多种格式，依赖众多解析器和第三方组件，攻击面较广，因此"应将其视为不可信的代码执行区域"。
他建议，图像处理应在专用沙箱或容器中隔离运行，或限制在具有最小文件系统访问权限的工作进程中执行，避免不必要的网络连接或对应用文件及机密的访问。应严格执行白名单策略，对文件内容进行人工验证，并在处理前扫描上传文件，将其存储在应用目录之外。
Seker还建议采取以下额外控制措施：使用短期且权限范围受限的凭据、限制出站网络访问、监控依赖项和软件组成，以及通过自动化测试确认升级后危险编解码器或操作已被禁用。
他指出："更深层的教训在于，企业不能仅凭'是否使用Rails'来评估自身的暴露风险。"他强调，即便两个应用运行相同版本的Rails，由于图像处理器、上传路径和操作系统软件包的差异，其实际风险敞口可能大相径庭。这使得对运行时配置、依赖库和应用功能的可见性变得至关重要。
他补充道，此次事件也再次凸显了漏洞响应中凭据轮换的重要性。"当漏洞允许任意文件访问时，安装补丁只是关闭了入口，但并不能撤销可能已被复制的凭据。"
Beauceron的Shipley指出，此次漏洞是软件物料清单（SBOM）的一个典型应用场景——SBOM可加速发现受影响软件并进行分类处置。企业还可在隔离系统、打补丁的基础上，引入智能Web应用防火墙进行监控和拦截。
"在任何严重漏洞中，你最不想听到的词就是'任意代码执行'和'远程代码执行'，"他说，"这两个词意味着麻烦。"
值得关注的是，此次漏洞的披露过程也遭到了"劫持"。Rails原计划在约一个月后才公开漏洞技术细节及取证工具，但由于多名研究人员通过逆向工程还原了攻击方式并发布了概念验证代码，相关信息被迫提前公开。
Seker指出，概念验证代码的公开"大幅提升了机会性扫描和利用尝试的可能性"。
因此，他表示："即便企业目前未发现明显的入侵迹象，也不应认为仅靠打补丁就能消除此前已暴露机密所带来的风险。"
Q&A
Q1：CVE-2026-66066漏洞是什么？它会造成哪些危害？
A：CVE-2026-66066是Ruby on Rails框架中Active Storage组件的一个高危漏洞，CVSS评分9.5分。攻击者无需账号即可通过上传恶意构造的图片文件，读取服务器上的敏感文件，甚至实现远程代码执行。可能泄露的信息包括数据库凭据、云访问密钥、API令牌以及用于签名会话的secret_key_base等核心机密。
Q2：哪些Rails应用会受到CVE-2026-66066漏洞影响？
A：使用libvips作为Active Storage图像处理后端（Rails 7.0起的默认配置），且接受来自不可信或未经身份验证用户上传图片的应用均受影响。仅升级Rails本身不够，libvips也必须升级至8.13或更高版本，才能彻底修复该漏洞。
Q3：发现CVE-2026-66066漏洞后，企业应该怎么做？
A：企业应立即将Active Storage升级至已修复版本（7.2.3.2、8.0.5.1或8.1.3.1），同时将libvips升级至8.13+。此外，还需轮换secret_key_base及所有相关凭据、使活跃会话失效，并审查日志以排查可疑上传或数据泄露迹象。安全团队应将此次事件作为潜在的机密泄露事故处理，而非仅仅完成补丁更新。