一个23MB的Brotli压缩请求体发过去，ClickHouse服务器在清理阶段崩了，正在跑的查询一起中断。这不是HTTP协议本身的问题，问题出在Google的Brotli解码器里。

打开网易新闻 查看精彩图片

JFrog的研究人员Aviv Engelberg、Eddy Tsalolikhin和Ofri Ouzan在10月25日发布的研究中，把编号CVE-2026-111497的漏洞沿着几条软件栈一路追了下去。结论是：只查Node.js版本，会漏掉其他暴露在外的软件。

漏洞的机制可以拆成三步看。一个非法的块切换被解码器误判成"还需要更多输入"，处理继续进行，但解码器状态已经坏了，于是写操作越过了原本的内存缓冲区。上游受影响版本包括Brotli 1.0.3到1.0.10之前、1.1.0到1.1.1之前、1.2.0到1.2.1之前。

这个漏洞最早在10月21日的Node.js安全更新中披露。Sysdig威胁研究团队的信息显示，修复版本为Node.js 22.23.4、24.22.1和26.12.1，其中24.22.1的发布说明确认了Brotli补丁。其他应用则需要各自的更新构建或库包。

不同软件踩中的坑还不一样：

  • FFmpeg：研究人员经libjxl进入解码器，libjxl负责处理JPEG XL图像。一张构造过的图片在压缩元数据盒里藏了畸形的Brotli数据，解码时内存损坏，清理阶段崩溃。测试显示攻击者能控制一个被破坏的指针值，但没有建立起针对FFmpeg的完整远程代码执行利用。
  • .NET：通过Brotli解压API触发原生崩溃。两阶段流让解码器进入非法状态，随后一次内存操作越出有效堆数据，进程以段错误终止，而不是抛出正常的托管异常。演示用的是本地控制台应用，但相关解码路径也可能服务于HttpClient响应解压和ASP.NET Core请求解压中间件。微软10月25日宣布为受支持的运行时和SDK推送更新。
  • ClickHouse：就是开头那个23MB请求的场景，解码器损坏导致清理阶段崩溃，测试服务器停止、活跃查询中断。JFrog称修复已合并，但研究发布时还没有带补丁的版本发出。
  • Apache Arrow：走的是另一条路。一个534字节的输入经pyarrow的Brotli解码路径，引发无限循环，持续消耗CPU且无法完成。同样的输入交给Brotli 1.2.1，不到一秒就被拒绝。Arrow的跟踪issue在发布时仍未关闭。

这里有个容易踩的坑：项目可以应用修复而不切换到上述上游版本，所以团队得去查厂商的补丁记录，光看版本号不够。

排查思路是把不可信的文件、缓冲区、请求和响应，一路追到解压代码那里。JFrog的扫描器能帮忙定位潜在路径，但扫出匹配本身并不等于可远程利用。