北京
一个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的扫描器能帮忙定位潜在路径，但扫出匹配本身并不等于可远程利用。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
