2026/10/28

Node2Shell（CVE-2026-111497）：哪些系统面临风险，现在该怎么做

Brotli 漏洞 CVE-2026-111497 实际影响哪些系统、各类场景的紧急程度，以及立即修补、重建、重启和缓解的步骤。

更新于 2026 年 10 月 27 日

CVE-2026-111497 俗称“Node2Shell”或“HTTP2Shell”，是 Brotli 解压器中的一个内存破坏漏洞。Brotli 即 Web 上广泛使用的 br 压缩格式。该漏洞存在于 Google Brotli 库 1.0.3 至 1.2.0 版本中 [1]。Node.js 内置了该库，Node.js 项目将此问题在 22.x、24.x 和 26.x 版本线上的严重性评为 High [2]。同一解码器还存在于 Python 软件包、Linux 系统库、桌面应用和开发者工具中，因此实际暴露面远不止“Node.js 服务器”。

本文面向需要快速判断自身是否受影响、以及首先该做什么的团队。

结论：只要您有任何系统会解压来自您无法控制的一方（互联网上的客户端、外部网站、Webhook 发送方、上传的文件）的 Brotli 数据，就应将此视为紧急事项。请打补丁、重建、重启，并在此期间拦截 br。

漏洞原理

解码器无法正确处理压缩流中格式错误的“块切换”（block switch）。它把该错误当作“需要更多输入”而不是“数据无效”，并不断向一个固定大小的小型内部缓冲区追加字节，直至越界写入 [2]。能够让您的应用解压精心构造的 Brotli 流的攻击者，可以破坏进程内存。这可能导致：

崩溃（拒绝服务）。这是最稳定可复现的结果。
进程内存泄露。响应或日志可能暴露密钥、令牌或其他用户数据的片段。
可能的远程代码执行。Node.js 将 RCE 列为可能的影响 [2]。首个公开的概念验证（PoC）仅在刻意削弱的构建上实现了代码执行，但此后研究人员报告称，在未经修改的官方 Node.js 24.22.0 构建上也实现了代码执行，只是成功率不稳定 [3]。

攻击无需身份验证：攻击者只需将字节送达解码器即可。这就是其 CVSS 4.0 评分为 9.2（Critical）的原因 [1]。因此，对每个系统而言，关键问题不是“我们是否使用 Brotli？”，而是“不受信任的一方能否让我们解压 Brotli？”

典型使用场景及其风险

场景 1：接受压缩请求体的面向互联网的 API（最高优先级）

部分 Node.js API 服务器、BFF、API 网关和上传端点会解压以 Content-Encoding: br 发送的请求体，也有一些通过中间件完成同样的操作。风险：互联网上任何匿名客户端都可以发送精心构造的请求体。影响从反复使服务崩溃（一种低成本的 DoS），到从持有会话数据和 API 密钥的进程中泄露内存不等。紧急程度：紧急。请今天就打补丁，并在完成之前在边缘拦截 br 请求体。

场景 2：从外部获取内容的服务（高优先级）

Webhook 消费方、爬虫和抓取工具、链接预览和 RSS 服务、支付或 SaaS 集成，以及浏览网页的 AI 智能体，都会发出出站 HTTP 请求。许多 HTTP 客户端会发送 Accept-Encoding: br 并自动解压响应。在 Python 中，只要安装了 Brotli 或 brotlicffi 包，urllib3 和 requests 就会这样做，即使您的代码从未导入它。aiohttp 也是如此，而 httpx 在安装了 brotli 扩展时同样会这样做 [4]。风险：恶意的、已被入侵的或被仿冒的远程服务器可以通过其响应攻击您的后端。攻击者完全不需要进入您的网络：是您主动调用了对方。紧急程度：高。凡是目标方不完全可信的地方，优先打补丁。

场景 3：内嵌运行时的桌面应用、AI 编程智能体和 CLI

Electron 应用、基于 Bun 或 Node 的 CLI 以及 AI 开发者工具都自带一份运行时副本。更新系统的 node 软件包并不能修复它们。更新磁盘上的应用也无法修复已在运行的副本：长时间运行的进程在重启之前会一直把旧运行时保留在内存中。风险：这些工具往往持有凭据并获取外部内容，相当于场景 2 再叠加一个高权限进程。紧急程度：对于获取不可信内容的工具为高。请更新它们，然后切实重启。关于“已更新却仍在运行旧代码”这一陷阱，我们在 HTTP2Shell：为什么更新二进制文件无法修复正在运行的进程一文中有详细介绍。

场景 4：容器镜像和 CI/CD 制品

在修复发布之前基于 FROM node:22、node:24 或 node:26 构建的镜像，即使宿主机已打补丁，仍包含存在漏洞的运行时。打包的 Python wheel 和 vendored 依赖同样如此。风险：在镜像重建之前，每次部署和每次自动扩缩容都会让漏洞代码卷土重来。紧急程度：对于场景 1 和 2 背后的镜像为高。请重建，而不仅仅是重启。

场景 5：Linux 系统库、字体和图像处理

各发行版以共享库形式提供该解码器，例如 Ubuntu/Debian 上的 libbrotli1。启用压缩时，curl 和 libcurl 会使用它；FreeType 处理 WOFF2 网页字体时会使用它；Pillow 等图像和文档工具也会间接使用它。风险：渲染用户上传的字体或文档的系统，或使用 curl --compressed 拉取外部内容的系统，可能接收到不可信的 Brotli 数据。从不向这些库输入外部数据的服务器，实际暴露程度较低。紧急程度：大多数情况下为中，但对于文档渲染或上传处理服务为高。Ubuntu 已为 22.04、24.04、26.04 和 26.10 发布了修复后的 brotli 软件包 [1]。对于 RHEL、Oracle Linux 及其他发行版，请查阅厂商针对 brotli 软件包的安全公告，不要自行假定其状态。

场景 6：仅处理可信输入的内部系统（较低优先级）

有些服务只解压您自己生成的 Brotli 数据，例如内部缓存或自有构建制品。这类系统风险较低，但并非为零：已经取得立足点的攻击者可以利用该漏洞进一步横向渗透。紧急程度：在下一个常规周期内打补丁。

应对措施：处置步骤

第 1 步：找出解码 Brotli 的位置（今天完成）

Node.js：在每台主机、每个容器镜像和 CI 运行器中检查 node -v。在代码和配置中搜索 brotliDecompress、createBrotliDecompress 以及会解压 br 的请求体解析中间件。
内嵌运行时：列出正在使用的 Electron 应用、Bun/Node CLI 和 AI 智能体，并记录每个工具内嵌的运行时版本，而不仅仅是应用版本。
Python：在每个环境和镜像中执行 pip show Brotli brotlicffi。在锁文件和 SBOM 中查找 httpx[brotli] 及传递依赖引入的情况。
操作系统软件包：执行 dpkg -l | grep brotli 或 rpm -qa | grep brotli，然后查看哪些进程实际加载了该库。
依据上述场景确定优先级：凡是不可信输入可以触达的（场景 1、2、3，以及涉及上传的场景 5）都排在最前。

第 2 步：修补受影响的组件

Node.js：升级到 22.23.4、24.22.1 或 26.12.1 及更高版本 [2]。
Python：Brotli>=1.2.1 或 brotlicffi>=1.2.1.0。重新生成锁文件 [4]。
上游 Brotli / vendored C 代码：根据分支，使用 1.0.10、1.1.1 或 1.2.1 [1]。
操作系统软件包：应用发行版针对 brotli / libbrotli 的安全更新。
桌面应用和智能体：更新到厂商明确说明已包含修复后运行时的版本。如果厂商尚未发布任何说明，应将该应用视为未经验证，而不是安全。

第 3 步：重建、重新部署并重启

基于已打补丁的基础镜像重建容器镜像并重新部署。重启旧镜像无济于事。
重启所有曾加载存在漏洞的库的长时间运行进程：Node 服务、worker、智能体会话，以及任何链接了该系统库的程序。对于有状态任务和 AI 智能体，请先排空或移交工作，以免丢失排队中的事件或审批。

第 4 步：在修补期间采取缓解措施

入站：在反向代理、负载均衡器或 WAF 上，于任何解码器处理之前拒绝 Content-Encoding 中包含 br 的请求体。
出站：仅从 Accept-Encoding 中移除 br 是不够的，因为恶意服务器仍然可以发送 br。还应拒绝或不解码带有 Content-Encoding: br 的响应 [4]。
Python 备用方案：如果升级必须推迟，可卸载 Brotli 和 brotlicffi，使客户端不再解码 br。请先进行测试，因为有些服务器仍会发送 br。

第 5 步：验证并留意被利用的迹象

在正在运行的进程或容器内部确认运行时版本，而不只是依赖包管理器的信息。
重新扫描镜像和 SBOM，确保没有旧副本仍通过传递依赖被引入。
检查近期日志，查看处理 br 的服务是否出现无法解释的崩溃、段错误或重启循环。来自单一来源的集中崩溃值得作为攻击尝试进行调查。
如果某个高暴露服务在打补丁前曾意外崩溃，鉴于无法排除内存泄露的可能，请考虑轮换该进程所持有的密钥。

总结

情况	风险	措施
公共 API 解码 `br` 请求体	严重	立即打补丁；在边缘拦截 `br`
后端获取外部 URL、Webhook 或网页	高	立即打补丁；拒绝 `br` 响应
内嵌运行时的 Electron 应用、AI 智能体或 CLI	高	更新并重启所有正在运行的实例
旧的容器镜像和 CI 制品	高	基于已修补的基础镜像重建并重新部署
用于上传、字体或 `curl --compressed` 的系统库	中–高	应用操作系统更新；重启加载该库的服务
仅限内部可信数据	低–中	在下一个周期打补丁

修补软件包只完成了一半工作。只有当所有正在运行的进程、镜像或内嵌运行时都无法再用旧代码解码不可信的 Brotli 时，暴露才算真正消除。