Cloudflare 紧急更新 WAF 规则集应对 Brotli 高危漏洞，默认只记录不拦截，网站管理员别急着点“阻止“

如果你的网站挂在 Cloudflare 后面，10 月 25 日这次 WAF 托管规则集的紧急更新值得停下手头的事情看一眼。它不是一次常规维护，而是奔着编号 CVE-2026-111497 的 Brotli 解码漏洞来的——一个被安全社区称作 Node2Shell 的内存越界写入缺陷，攻击者只需让服务端解压一段精心构造的 Brotli 压缩数据，就有可能在目标机器上远程执行任意代码。Google 作为漏洞编号机构给它打出了 CVSS 4.0 9.2 的临界评分，Node.js 官方则将其定级为高危。好在 Cloudflare 这次的态度相当克制：新增的两条规则虽然默认启用，但动作全部设为"日志"，也就是只观察、不拦截。

两条规则分别盯住了两条攻击路径。第一条匹配请求头中携带 Content-Encoding: br 的入站请求，也就是声明了请求体采用 Brotli 压缩的流量。这里有一个极易混淆的细节必须说清：它匹配的是请求体上的 Content-Encoding，而不是客户端常见的 Accept-Encoding。换句话说，浏览器日常宣告"我支持 Brotli"这件事完全不会触发这条规则，你的访客不会因此受到任何影响。同样不受影响的是 Cloudflare 自己的 Brotli 响应压缩功能，站点照常开启压缩提速，这次更新与出站压缩设置毫无关系。

第二条规则的照顾对象是使用 Next.js 框架的网站。它会匹配打到 /_next/image 这个图像优化端点上的请求，而这恰恰是 Next.js 应用正常加载图片的必经之路。Cloudflare 在公告里把话说得很直白：这两条规则的标识符分别以 ca706f3c 和 402fe5bb 结尾，描述均为 CVE-2026-111497 相关的新增检测。它们的共同点是"匹配不等于攻击"——大量正常业务流量也会命中，这正是默认动作为什么只能是记录。

真正需要警惕的是一个容易踩进去的坑：规则集级别的操作覆盖。如果你过去为了收紧防护，曾经给整个托管规则集配置过"阻止"之类的覆盖动作，那么这些历史设置可能直接压过新规则的默认日志动作。结果就是，你以为自己在安安静静收集日志，实际部署完成的瞬间，合法的 Brotli 压缩请求和正常图片流量已经被成批挡在门外。Cloudflare 给出的做法是部署前先检查一遍既有的覆盖配置，在需要评估流量的阶段为这两条规则单独套用日志覆盖，跑几天数据看匹配情况，确认误报可控之后再决定是否升级为阻止。

再往源头追一步，这个漏洞本身值得每一个用 Node.js 的团队认真对待。它出自 Node.js 内置的 Brotli 解码器，是一段两个月前就悄悄合入 Brotli 上游源码、却始终没有随任何安全版本发布的修复，直到 10 月 21 日 Node.js 一次性放出 22.23.4、24.22.1 和 26.12.1 三个修复版本，这个坑才算被填上。坏消息是覆盖面远比想象中广：Express 5 会默认解压带 Brotli 编码的请求体，Node 内置的 fetch 在收到 Content-Encoding: br 的响应时也会自动解码，很多应用根本没写过半行 Brotli 代码，却早已站在漏洞的射程之内。Imperva 红队随后公开的演示更是在官方 Node.js 24.22.0 镜像上完成了代码执行。已经停止支持的旧版本——包括 Node.js 20、23、25 及更早线路——则不会有任何补丁，唯一的出路是迁移到受支持的版本。

把两层防线放在一起看，结论就很清晰了。Cloudflare 的 WAF 规则解决的是边界问题，在流量入口帮你观察甚至挡下可疑的 Brotli 载荷；而运行时补丁解决的是根本问题，只有把每一个正在运行的 Node.js 实例——包括容器镜像、CI 环境和长期没人动的 Lambda 函数——都升级到修复版本并重新部署，才算真正关上了这扇门。对于日志里冒出来的匹配记录，也别急着当成攻击事件处理，先分清是正常流量还是异常模式，再决定要不要开阻止。防火墙可以帮你争取时间，但补丁，永远要打在最后一行代码跑着的那台机器上。