Rails Active Storage 漏洞：11 月 7 日前请检查这三项设置

CVSS 9.8 的 Rails Active Storage 漏洞可让攻击者通过一次图片上传在服务器上写入文件。请检查三项设置、尽快升级，并留意 Rails 8.0 的支持截止日期。

几乎所有接收头像、文档或商品照片的 Rails 应用，都会通过 Active Storage 处理这些文件。2026 年 11 月 4 日，Rails 团队针对这一上传路径发布了严重级别的安全公告。在一些常见配置中，只需一次精心构造的上传，未经身份验证的攻击者就能在服务器上写入文件。

是否受影响取决于三项很容易检查的设置。本文将介绍该漏洞的原理、每项设置的检查方法，以及暂时无法升级时可以采取的措施。使用 Rails 8.0 的团队尤其需要关注，因为该分支的安全支持将于 2026 年 11 月 7 日结束。

漏洞原理

附加文件时，Active Storage 会运行分析器来读取图片尺寸等基本信息。使用 :mini_magick 处理器时，分析器会把文件交给 ImageMagick 处理。ImageMagick 通过名为编码器（coder）的模块支持多种格式，其中一些功能非常强大：修复提交中展示了上传的 SVG 如何触达 MSL 编码器，而 MSL 是一种脚本格式，可以读写脚本中指定的文件。Active Storage 没有限制上传文件可以触达哪些编码器，因此服务器上的 ImageMagick 策略成了唯一的防线。

有两点让这个问题尤为严重。第一，分析器在附加文件时就会运行，无需生成变体或预览，也无需显式调用 analyze，只要接收上传就足以触发。第二，对于使用 Disk 服务存储文件的应用，攻击者还能读取应用进程可读的任意文件，其中包括 secret_key_base 以及其他系统的凭据，进而可能导致远程代码执行或横向移动。

该漏洞由 GMO Flatt Security 的 RyotaK 通过 HackerOne 报告。Rails 团队表示，目前报告的攻击链只有一条，但他们并不认为这是唯一的一条。公告未说明该漏洞是否已被利用。

判断是否受影响的三个条件

只有三个条件同时成立时才会受影响。请按顺序检查；只要有一个不成立，这条攻击链就不适用，不过升级仍然是正确的做法。

条件	检查位置	受影响的情形
1. 变体处理器	config.active_storage.variant_processor 和 load_defaults	值为 :mini_magick（load_defaults 6.1 及更早版本的默认值）
2. ImageMagick 策略	服务器上的 policy.xml	未屏蔽 MSL、Ghostscript 相关编码器和 gs 委托（Debian 和 Ubuntu 的默认策略均未屏蔽）
3. 谁可以上传	上传表单和 API	不受信任的用户可以附加文件

1. Active Storage 使用的是哪种处理器？

搜索配置文件，并直接在运行中的应用里查询：

grep -rn "variant_processor\|load_defaults" config/
bin/rails runner 'p Rails.application.config.active_storage.variant_processor'

从 Rails 7.0 起默认值为 :vips，但从旧版本升级而来的应用往往仍在加载旧的默认值，或显式设置了 :mini_magick。另外请检查 bundle info mini_magick：如果该 gem 在你的依赖包中，请查明它在哪里被使用。

2. ImageMagick 策略是否屏蔽了危险的编码器？

在每台应用服务器和 worker 上列出 ImageMagick 实际加载的策略：

magick -list policy      # ImageMagick 7
convert -list policy     # ImageMagick 6

检查是否存在针对 MSL 编码器、PostScript 和 PDF 编码器以及 gs 委托的 rights="none" 规则。如果直接使用 Debian 或 Ubuntu 软件包自带的策略而未做修改，请默认它们没有被屏蔽。还要注意，容器镜像和 worker 主机上运行的 ImageMagick 版本可能与 Web 服务器不同。

3. 不受信任的用户能否上传文件？

列出文件会到达 attach、has_one_attached 或 has_many_attached 的所有位置，包括 API、直接上传以及从外部导入文件的管理工具。带头像字段的公开注册也应视为不受信任的来源。

修复方法：各分支的升级路径

修复版本为 Rails 8.1.4.1 和 Rails 8.0.5.2。这两个版本共修复了 21 个安全问题，因此即使不受本漏洞影响，也值得安装。

你使用的分支	应对措施
8.1	升级到 8.1.4.1
8.0	立即升级到 8.0.5.2，然后规划迁移到 8.1：8.0 的安全支持将于 2026 年 11 月 7 日结束
7.2 及更早版本	不会发布修复版本。请采用下文的策略临时方案，并升级到 8.0 或更高版本

使用 :mini_magick 的应用还需要 mini_magick 5.1 或更高版本。如果版本较旧，修复版本会在启动时报错，因此请同时更新这两个 gem，并在预发布环境中测试启动：

bundle update rails mini_magick
bundle info activestorage
bundle info mini_magick

修复版本自带 ImageMagick 策略，但请确认它确实作用到了 ImageMagick。如果应用在启动后替换了 MiniMagick.cli_env、使用了 MiniMagick.cli_prefix，或安装了自定义的 MiniMagick::Shell，该策略就不会生效，这类应用需要在系统策略中添加规则。GraphicsMagick 完全不读取 ImageMagick 策略。此外，自带策略是叠加到服务器的 policy.xml 上，而不是替换它，因此那里的允许规则（包括通配符）会覆盖屏蔽规则。

同一批版本还修复了第二个漏洞 GHSA-v924-7rp8-4mxh（CVSS 8.8）。Active Storage 将上传文件以保留原始扩展名的临时文件名传给 ImageMagick 和 FFmpeg，因此能够控制文件名和声明内容类型的攻击者，可以影响实际运行的解码器。Rails 针对该漏洞给出的临时方案只覆盖 FFmpeg，这也是应当升级而不是依赖临时方案的又一个理由。

这是一种模式，而非个例

2026 年 7 月，CVE-2026-66066 是另一个独立的严重 Active Storage 漏洞，影响使用 libvips 的应用。使用 ImageMagick 的应用当时不受那条路径影响，但会受到本次漏洞的影响。四个月内，两个受支持的图片库各出现一个严重漏洞，说明的是同一个道理：图片处理是一个很大的攻击面，而 Active Storage 会在陌生人上传的文件被附加的那一刻就对其进行处理。

仅仅更换处理器并不能解决问题。真正的保护在于把图片库视为攻击面的一部分：像对待框架一样及时打补丁，用策略加以限制，并清楚哪些主机在运行它。尤其是 ImageMagick 策略，它是存放在操作系统镜像而非应用代码中的服务器设置，很容易被遗忘。

如果无法立即升级

Rails 还发布了针对 8.1 和 8.0 的补丁提交。在能够部署修复版本之前，请按以下清单逐项处理：

1. 在每台处理上传的主机上，将公告中的最小规则添加到 ImageMagick 的系统策略中（例如 /etc/ImageMagick-7/policy.xml）。
2. 确保同一文件中没有允许规则或通配符覆盖这些规则，然后用 magick -list policy 确认。
3. 如果需要通过 ImageMagick 渲染 PDF 或 PostScript，请重新允许 gs 委托和确实需要的编码器，并接受由此保留的一定风险。
4. 限制上传：暂时收紧可以附加文件的用户范围，或暂停匿名上传。
5. 如果使用 Disk 服务，请规划轮换 secret_key_base、主密钥、config/credentials.yml.enc 中的内容、存储和数据库凭据以及第三方令牌。不要将已暴露的密钥保留作为后备。

公告中发布的最小规则如下：

<policy domain="coder" rights="none" pattern="MSL"/>
<policy domain="delegate" rights="none" pattern="gs"/>
<policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,EPS2,EPS3,EPI,EPSF,EPSI,EPT,EPT2,EPT3,PDF,AI,EPDF,PDFA,POCKETMOD,XPS,PCL}"/>

完整详情请参阅 Rails 安全公告。

LOGIQ 能提供的帮助

LOGIQ 为在 Linux 上运行开源技术栈的团队提供支持，覆盖从操作系统镜像到应用运行时的各个层面。如果您需要协助检查各服务器上的 ImageMagick 策略，或规划从即将停止支持的分支迁移，欢迎联系我们的团队。