HTTP2Shell攻击.NET——为何安全补丁只是半套方案

这个补丁未能切中要害

微软于10月25日发布了面向.NET 8（v8.0.33）、.NET 9（v9.0.22）和.NET 10（v10.0.14）的紧急带外安全更新，并为.NET 11提供了发布候选版本。该修复针对的是CVE-2026-111497——Google Brotli解压缩库中存在的一个内存损坏缺陷，该漏洞也被称为Node2Shell或HTTP2Shell。

这种双重命名本身就是一个信号：这并非单一厂商的漏洞。它存在于Brotli压缩格式中，而该格式被Node.js、Python、Bun、Envoy以及微软的运行时栈广泛采用。该漏洞允许未经身份验证的攻击者读取或破坏进程内存，从而导致信息泄露、服务拒绝或权限提升。

安装补丁只是简单的部分，真正的风险隐藏在理解谁仍处于暴露状态之中。

这不仅仅是一个.NET的故事

Windows Magazine（窓の杜）的日语报道强调了操作细节——版本号、补丁层级、容器重建说明——这些内容西方媒体跟进较慢。这里的差距很重要，因为HTTP2Shell本质上是一个供应链问题，而非产品问题。

Brotli已深深嵌入几乎所有现代Web栈的压缩流程中。控制或拦截客户端与启用Brotli的服务端之间流量的攻击者，可以构造畸形压缩负载以触发内存损坏。同样的漏洞最早出现在Node.js中，因此得名Node2Shell，但它并不尊重运行时边界。它存在于解压缩层，在HTTP响应体被解包后才会进入你的应用程序代码之前就已经生效。

微软将PowerShell更新与Visual Studio及.NET运行时补丁一同发布，表明组织已认识到问题并未局限于单一组件。CVE-2026-114148——一个允许本地权限提升的Linux特定tarball所有权元数据漏洞——也在同一时间窗口内被修复，这进一步强化了.NET的攻击面不仅限于压缩库这一事实。

自包含部署的陷阱

以下是大多数漏洞时间线在最初几天会忽略的内容：带外补丁仅对运行操作系统共享.NET运行时的环境有效。

如果你的应用是自包含的——即.NET运行时与应用二进制文件一同分发，而非依赖操作系统安装的版本——那么在主机构装更新的运行时毫无意义。应用程序将继续使用其捆绑的运行时。对于固定特定.NET镜像标签的容器化部署，同样如此。如果不重新构建并重新部署，仅拉取更新的基镜像仍会使漏洞保持存在。

微软对此说法明确。指导文件指出，组织必须使用更新后的运行时重新构建并重新分发自包含应用程序。容器需要基于已修补的镜像重新构建。仅更新主机操作系统无法解决问题。

这一区别将区分哪些组织会漏网，哪些不会。许多企业运行数百甚至数千个自包含微服务，每个服务都在不同时间以不同运行时版本编译。仅清点资产就是一项非平凡的任务。

默认状态与隐藏风险

微软立场中有一线希望：.NET默认禁用Brotli请求解压缩和响应解压缩。如果你的应用从未显式启用这些功能，你很可能不受CVE-2026-111497解压缩路径的影响。

但一旦依赖树中任何库直接调用System.IO.Compression的Brotli API，这种保护就会消失。第三方包，即使不将压缩作为功能宣传，也可能在内部路由流量通过Brotli——尤其是处理由上游CDN或负载均衡器压缩的HTTP响应时。

这正是审计纪律发挥作用的地方。运行dotnet --list-runtimes可以告诉你操作系统是否已修补，但它无法告诉你应用代码或其传递依赖是否在进行直接Brotli调用。开发者需要检查自己的依赖关系图。

接下来会发生什么

.NET 11 Release Candidate 3已经可用，微软敦促RC2用户使用升级。这种模式——在发布周期中期披露关键漏洞时推动早期采用者向最新候选版本迁移——是标准做法。这表明修复被认为足够稳定可用于.NET 11的生产部署，但组织希望将RC3用户从可能携带其他未修复问题的旧候选版本中移开。

CVE-2026-70197（10月13日更新中不完整的一个SocketAsyncEventArgs内存损坏漏洞）和CVE-2026-102870（Blazor WebAssembly调试器缺陷）的同时修补表明，微软的10月更新周期相当艰难。两个此前已修补的漏洞在同一时间窗口需要后续修复。这种模式提高了其他问题存在于近期发布版本中尚未浮现的可能性。

真正的启示

HTTP2Shell提醒我们，压缩库是安全边界的一部分。Brotli、Deflate、GZIP——这些不是实现细节。它们是攻击面。

补丁已经存在，版本号已公布。更难的工作是回答：哪些服务使用自包含部署？哪些容器需要重建？哪些第三方库直接调用Brotli API？有多少.NET 8、9和10安装因为没有检查而运行着未更新的运行时？

仅Windows的.NET Framework不受影响，界限清晰。其余一切——并且还有大量其余——需要在下一次漏洞利用出现前得到关注。