CVE-2026-111497：一个 Brotli 漏洞、九个运行时，以及发现它的 Codex Agent

CVE-2026-111497 的棘手之处在于，它并非某一个产品中的某一个漏洞。它是 Google 的 Brotli 解压器中的一处越界写入，而同一个缺陷可以通过至少八个内嵌该库的独立运行时和代理被触发——Node.js、.NET 和 ASP.NET Core、Python 的 Brotli 和 brotlicffi、Bun、Envoy、Istio，以及纯 Go 实现。Wiz 的测量结果显示，91% 的云环境面临风险，并指出其中 82% 将 Node.js 公开暴露。CISA 已将其列入"已知被利用漏洞"目录，微软也为 .NET 和 Visual Studio 发布了紧急补丁。

故事的后半部分讲的是谁发现了它：根据 Wiz 的报道和上游致谢信息，发现者是 OpenAI Codex Security 的 Khai Tran 和 Sylvie Mayer。那是一个 AI 安全智能体团队，而它发现的漏洞存在于网络上嵌入范围最广的那个解压缩库中。

这个 bug 会做什么

Brotli 是几乎所有 HTTP 栈在服务器发送以下标头时会解压的内容：code>Content-Encoding: br/code>。畸形的压缩流会在解压期间导致越界写入，CVSS v4 评分为 9.2。受影响范围为 Brotli 1.0.3 至 1.2.0，已在 1.0.10、1.1.1 和 1.2.1 中修复。

它之所以是一项计划而非一张工单，是因为该库在每个运行时中都是以随项目附带、静态链接或重新实现的形式存在，因此修复在每种情况下都要通过不同的发布节奏抵达——有时甚至根本不会抵达，因为某门语言的标准发行版自带一份副本。

补丁列表，才是有用的部分

以下所有数据均来自 Wiz 的安全公告摘要以及各项目的发布说明，查阅日期为 2026 年 10 月 30 日。

• Google Brotli / libbrotli — 受影响版本为 1.0.3–1.2.0（不包括已修补的向后移植版本）；已在 1.0.10、1.1.1、1.2.1 中修复。

• Python Brotli — 受影响版本为 1.0.3–1.2.0；已在 1.2.1 中修复。 brotlicffi — 受影响版本为 1.0.3–1.2.0.x；已在 1.2.1.0 中修复。

• Node.js — 受影响版本：22.x、24.x 和 26.x；已在 22.23.4、24.22.1 和 26.12.1 中修复。

• Bun — 受影响版本 1.0.21–1.4.3；已在 1.4.4 中修复。

• Envoy Proxy — 受影响版本：1.36.11、1.37.7、1.38.5、1.39.2；已在 1.36.12、1.37.8、1.38.6、1.39.3 和 1.40.0 中修复。

• Istio — 受影响版本为 1.29.0–1.29.8、1.30.0–1.30.5、1.31.0–1.31.1；已在 1.29.9、1.30.6 和 1.31.2 中修复。

• andybalholm/brotli (Go) — 在 v1.2.7 之前受影响；已在 v1.2.7 中修复。

Node.js 这一行，决定了大多数人的一周。运行在 22.22.x 上的服务，即便其应用代码从未提到 Brotli，也会通过它的 HTTP 栈暴露出来，因为解压缩发生在你的处理函数被调用之前。这也解释了业界给它贴上的三个名字：针对 Node 路径的 Node2Shell、Check Point 记录在案的代理路径 HTTP2Shell，以及 JFrog 从更宏观视角命名的 Brotli2Shell。

为什么“91%”是那个值得争论的数字

Wiz 的数据描述的是 Wiz 客户的云资产，而不是整个互联网。统计“某个环境中某处存在一个有漏洞的库”并不等于统计可利用的服务，两者差距巨大：桌面应用中捆绑的 Brotli 如果从不 decompress 不可信输入，那只是一个发现，而不是漏洞。更有用的统计口径要窄得多——即那些接受来自不可信来源的压缩输入的服务，而这基本上就是每一个公共 HTTP 端点，它们终止于 code>br/code>.

有两个因素让漏洞利用不只是理论上的可能，而是确有现实可能：CISA 将该漏洞加入 KEV 目录，意味着已观察到实际利用；蜜罐运营者也记录到了利用尝试。当某个漏洞跨入“已在野利用”这一栏时，补丁截止日期就不再由你的变更控制日程决定，而变成了别人的日程。

发现是半衰期较长的部分。

一个前沿模型的安全团队在一个解压缩库中发现了一个内存安全漏洞，而这个库在十多年间已被成千上万人读过。这不是一个关于某家厂商多么聪明的故事；这是一个关于覆盖范围的问题。静态分析已被用于 Brotli 多年，模糊测试框架也已存在，而该漏洞却在两者之下存活了下来——与此同时，一个专为有目的地阅读代码而设计的智能体发现了它，并产出了一个被上游接受的修复。

这种不对称是双向的。能发现这一类漏洞的能力，同样也能在你交付的代码中发现它。对于任何使用智能体编程的人来说，问题不在于智能体能否发现越界写入，而在于这一发现是先送到你手上，还是先送到别人手上。

该做什么，按重要程度排序

• 为你实际运行的运行时打补丁。上面的库列表是依据；从那些终止公共流量的运行时开始。

• 然后寻找随代码附带的副本。容器基础镜像、静态二进制文件、WASM 构建产物和语言 wheel 包各自都带有自己的 Brotli，而它们都不会出现在应用程序的包管理器审计中。本周发布的一款仓库级清单扫描器会遍历文件系统，并对它找到的每一个 Node、Bun 和 Brotli 副本进行分级，这比自行发明一个扫描器更快上手。

• 尽可能重新构建，而不是打补丁。在已构建的构件中替换静态链接的库，正是人们不小心发布半修复二进制文件的地方。

• 如果你将 Envoy 或 Istio 作为边缘运行，请把代理相关的修复视为本组中优先级最高的事项：代理会代表其背后的所有内容进行解压缩。

• 单独检查你的 .NET 资产。Microsoft 的补丁涵盖 .NET 和 Visual Studio，正确的版本是运行时更新，而不是包引用变更。

这对我们的读者意味着什么

本博客的大部分内容涉及模型能力、价格和路由。这件事之所以属于这里，是因为有一句话：这个缺陷是由一个 AI 智能体发现的，而能够发现这类 bug 的系统类别，正是我们的读者正在接入其流水线的那类系统。在 CI 中针对你的依赖运行的仓库扫描智能体如今是一种安全控制，而它正是编写你的代码的那个智能体运行时。

OrcaRouter 的 Agent Firewall 会在工具调用和 MCP 调用执行之前对其进行评级，这正是限制智能体影响范围的控制措施；它并不能让智能体的发现结果变得正确，而且关于这个 CVE，也完全没有声称对模型进行路由就能降低供应链风险。这一周真正值得吸取的东西更具体、也更可核查：如果你给了某个智能体仓库读取权限来查找漏洞，那么请核实它提出的补丁是否已固定版本，并核实你自己技术栈底层的运行时是否已经越过了 1.0.3–1.2.0。

值得记住的模式是：漏洞存在于没人主动选择的代码里。Brotli 是作为某个运行时功能的传递依赖出现的，在八个地方按各自不同的时间表被修复，而且还会继续出现在本周之前构建的基础镜像中。供应链应对在很大程度上就是一项纪律：找出那些并非由你安装的副本。

来源说明：受影响版本与已修复版本的对照矩阵、运行时列表，以及 91%/82% 的暴露比例数据，均来自 2026 年 10 月 30 日查阅的 Wiz 公告摘要；已修复版本则取自各项目自身的发布版本。9.2 的 CVSS v4 评分来自 CVE 记录。发现者归功于 OpenAI Codex Security 的 Khai Tran 和 Sylvie Mayer，此信息来自 Wiz 的撰文以及上游致谢。CISA 的 KEV 收录和 Microsoft 的 .NET 补丁分别来自相应机构的公告；除公告摘要外，本文并未将这些公告作为一手文件查阅。清单扫描器的描述来自一个第三方 GitHub 项目自身的说明。