CVE-2026-111497：CVSS 9.2！Google Brotli 解压缩缓冲区溢出漏洞，可导致远程代码执行

摘要： 2026年10月，Google Brotli 解压缩组件曝出严重的越界写入漏洞 CVE-2026-111497，CVSS 4。0 评分高达 9。2。攻击者可通过精心构造的压缩数据破坏应用程序内存，造成服务崩溃、敏感信息泄露甚至远程代码执行。漏洞波及 Nodejs、。NET、Python 等多个生态，已有公开 PoC 和真实利用活动。本文介绍漏洞原理、影响范围、自查方法及修复方案。

一、漏洞概述

Brotli 是 Google 开发的一种开源数据压缩算法，广泛应用于网页传输、文件压缩及应用程序通信。

如果打开浏览器的开发者工具，查看某些 HTTP 响应头，可能会看到：

Content-Encoding： br

其中的 br 就代表 Brotli 压缩格式。

Brotli 的优势是压缩率高，尤其适合 HTML、CSS、JavaScript 等文本资源。大量 Web 服务器、浏览器和编程语言运行时都支持这种压缩方式。

2026年10月21日，Nodejs 项目发布安全公告，披露其内置的 Brotli 解码器存在严重内存安全问题。

该漏洞被分配编号 CVE-2026-111497，并于10月22日正式进入 CVE 数据库。

随后，安全研究人员确认，问题源于 Google Brotli 的底层 C 语言解码实现，因此影响范围远超 Nodejs。

漏洞在安全社区中还被称为 Node2Shell、Broccoli2Shell 或 HTTP2Shell。

1。 基本信息

CVSS 4。0 评分向量：

CVSS：4。0/AV：N/AC：L/AT：P/PR：N/UI：N/VC：H/VI：H/VA：H/SC：N/SI：N/SA：N

其中，AV：N 表示可以通过网络攻击，PR：N 表示无需预先获得账户权限，AT：P 表示利用过程中仍需要满足特定条件。

2。 哪些版本存在问题？

Google Brotli 官方确认的受影响版本及修复版本如下：

三个分支的修复版本均已发布。

需要注意，部分 Linux 发行版会将安全补丁回移到较旧的软件版本，因此实际判断应结合发行版的安全公告和软件包修订号。

二、漏洞原理：一个错误返回值，为什么会导致内存溢出？

这个漏洞的核心原因是：

Brotli 解码器在遇到非法压缩数据时，没有正确终止解码过程，导致后续数据持续写入容量有限的内部缓冲区。

1。 Brotli 解压缩是如何工作的？

Brotli 压缩数据通常由多个数据块组成。解码器需要读取压缩数据中的控制信息，判断接下来应该如何恢复原始内容。

典型流程如下：

接收 Brotli 压缩数据
          |
          v
解析数据块头部
          |
          v
读取数据块类型和长度
          |
          v
执行对应解码逻辑
          |
          v
输出解压后的数据

在正常情况下，解码器遇到不符合格式要求的数据，应立即返回错误。

例如：

// 简化示意代码，并非 Brotli 原始源码

if (block_type_is_invalid) {
    return ERROR_INVALID_DATA;
}

调用方收到错误后，就应该停止解码。

问题在于，存在漏洞的实现没有始终正确处理这种情况。

2。 错误发生在哪里？

Brotli 的 c/dec/decode。c 文件中包含处理数据块类型切换的代码。

其中一个关键函数是：

DecodeBlockTypeAndLength()

该函数负责解析数据块的类型和长度。

根据 Nodejs 官方公告及 Python 安全公告数据库披露的信息：

1。 攻击者构造包含非法数据块切换信息的 Brotli 压缩流。
2。 解码器进入异常的数据块处理分支。
3。 相关函数返回的状态存在歧义，部分解码路径也未正确处理其返回结果。
4。 本应终止的解码操作，被错误地当作暂时需要更多输入数据。
5。 流式解码器继续向内部缓冲区追加数据。
6。 最终发生越界写入，破坏相邻内存。

Nodejs 官方特别指出，相关路径会持续向一个只有 8 字节的内部缓冲区写入数据。

可以通过下面的伪代码理解：

// 漏洞机制示意，并非原始实现

char buffer[8];
size_t position = 0;

while (need_more_input) {
    // 错误状态被当成继续读取输入
    // 且缺少有效的边界检查

    buffer[position++] = next_byte();
}

当 position 超过缓冲区容量时，数据就可能写入相邻内存。

实际漏洞涉及更复杂的状态机、快速解码路径及缓冲区处理逻辑，上述代码仅用于解释越界写入的基本机制。

3。 为什么越界写入如此危险？

假设程序内部的内存布局如下：

正常情况：

┌──────────────────┐
│ Brotli 数据缓冲区 │
│ 8 Bytes          │
├──────────────────┤
│ 解码器内部状态    │
├──────────────────┤
│ 其他程序数据      │
└──────────────────┘


发生越界写入：

┌──────────────────┐
│ Brotli 数据缓冲区 │
│ 已填满            │
├──────────────────┤
│ 被覆盖的内部状态  │ ← 非法数据写入
├──────────────────┤
│ 其他程序数据      │
└──────────────────┘

攻击者一旦能够影响相邻内存，就可能造成三类后果。

第一，拒绝服务（DoS）。

非法内存访问可能导致程序异常退出，使服务中断。

第二，敏感信息泄露。

内存破坏可能使程序在后续操作中读取或返回原本不应暴露的数据。

第三，远程代码执行（RCE）。

在特定内存布局及运行条件下，攻击者可能进一步利用内存破坏改变程序执行流程。

但从越界写入发展到稳定的远程代码执行，需要进一步满足内存布局、利用原语和目标环境等条件。

因此，漏洞的 CVSS 评分虽然达到 9。2，也需要结合实际部署方式评估攻击成功的难度。

三、影响范围：哪些人需要担心？

这个漏洞最值得关注的特点，是它影响了多个软件生态。

1。 Nodejs 开发者

Nodejs 在 node：zlib 模块中支持 Brotli 解压缩。

例如：

const zlib = require("node：zlib");

const decoder = zlib。createBrotliDecompress();

如果应用程序接收外部提供的 Brotli 压缩数据，并将其交给存在漏洞的解码器处理，就可能形成攻击入口。

需要特别关注：

• 接收压缩请求体的 Web 服务；
• 上传并解析 Brotli 压缩文件的接口；
• 从不可信远程服务获取压缩数据的应用；
• 自动处理外部 Brotli 数据的代理或中间件。

Nodejs 官方发布的修复版本如下：

其中，Nodejs 24。22。1 随后发现了其他回归问题，官方于10月28日发布 24。22。2 修正。24。x 用户建议至少升级至24。22。2。

Nodejs 20。x、25。x 等已结束维护的分支，需要迁移到受支持的版本。

2。 Python 开发者

Python 生态中的 Brotli 压缩库同样受到影响。

例如，某个 Python 服务使用 requests、httpx 等 HTTP 客户端访问不可信服务器。

如果相关环境安装了存在漏洞的 Brotli 解码库，并自动解压服务器返回的恶意压缩内容，就可能触发漏洞。

这里有一个容易忽略的情况：

即使业务代码从未直接调用 Brotli，也可能通过第三方 HTTP 库间接使用它。

3。 。NET 开发者

微软确认，。NET 中使用的 Brotli 解码器同样存在该问题。

对应修复版本包括：

使用 BrotliStream、BrotliDecoder，或者主动启用 Brotli 自动解压功能的程序需要重点检查。

微软指出，ASP。NET Core 请求解压缩和 HttpClient 响应自动解压缩在默认配置下均未开启。

因此，需要根据应用是否实际处理攻击者可控的 Brotli 数据判断风险。

。NET Framework 不受此次微软公告所述漏洞影响。

4。 Linux、容器及云平台

受影响的 Brotli 库还可能被集成在：

• Linux 系统软件包；
• Docker 容器镜像；
• 反向代理和服务网格组件；
• 云函数运行环境；
• 部分安全设备和企业基础设施产品。

Debian、Ubuntu、Alpine 等发行版已发布对应的安全更新或回移补丁，具体版本应以发行版公告为准。

此外，Microsoft、AWS、Palo Alto Networks、Broadcom 等厂商也陆续发布了相关安全公告。

判断风险最重要的问题是：攻击者是否能够让目标程序使用受影响的 Brotli 解码器处理其控制的数据。

例如，服务器只是使用 Brotli 压缩网页并向浏览器发送，通常不会因此触发该解码漏洞。

如果服务器接收客户端提交的 Brotli 压缩请求体并进行解压，则需要重点关注。

四、风险分析：是否已经出现真实攻击？

截至2026年11月3日，公开信息已经能够确认三个事实。

1。 已有公开 PoC

该漏洞公开后，安全社区陆续出现概念验证代码。

新西兰国家网络安全中心（NCSC）在10月29日的公告中明确确认，已经发现针对该漏洞的公开 PoC。

英国 NHS England 的安全通报也提到，研究人员报告了针对 Nodejs 24。22。0 的成功代码执行测试，但可能需要多次尝试。

因此，公开 PoC 的存在已经得到确认，实际执行代码的稳定性和适用环境仍需要分别评估。

2。 已被证实存在在野利用

2026年10月27日，美国 CISA 将 CVE-2026-111497 加入已知遭利用漏洞目录（KEV）。

这意味着该漏洞已经具有真实利用证据，安全团队应优先安排修复。

新西兰 NCSC 同样确认已知悉活跃利用活动。

不过，公开公告尚未完整披露具体受害者、入侵规模或完整攻击链。

3。 已观察到自动化扫描和可疑攻击流量

Check Point 于10月29日发布的研究指出，其安全设备遥测中已经发现：

• 包含 Brotli 压缩数据的可疑 HTTP 请求；
• 自动化漏洞探测行为；
• 针对上传和数据接收接口的定向探测；
• 异常二进制载荷及 HTTP 500 错误。

这些遥测记录主要证明了扫描和疑似利用尝试，单条异常请求或服务器错误仍需要结合其他日志判断是否成功入侵。

考虑到漏洞已进入 KEV，建议将可从外部访问的相关服务列为优先修复对象。

五、自查方法：如何确认自己的系统是否受影响？

1。 检查 Nodejs 版本

在终端执行：

node -v

查看 Nodejs 内置的 Brotli 版本：

node -p "process。versions。brotli"

同时检查代码中是否存在相关调用：

grep -RIn \
  --exclude-dir=node_modules \
  --exclude-dir=。git \
  -E 'createBrotliDecompress|brotliDecompress|BrotliDecompress' \
  。/src

这个命令用于查找常见的显式解压调用，第三方依赖及自动解压路径仍需另行检查。

2。 检查 Python 依赖

执行：

python -m pip show Brotli brotlicffi

或者：

python -m pip list | grep -i brotli

如果发现受影响版本，可以进一步执行：

python -m pip check

检查更新依赖后是否存在兼容性问题。

3。 检查 Linux 系统库

Ubuntu / Debian：

dpkg-query -W libbrotli1 nodejs

RHEL / Rocky Linux / Fedora：

rpm -q brotli nodejs

同时检查可用的安全更新。

Debian / Ubuntu：

sudo apt update
apt list --upgradable

RHEL 系列：

sudo dnf updateinfo list security

需要注意，发行版软件包可能已经回移补丁，判断时应结合软件包修订号和厂商安全公告。

4。 检查 。NET 运行环境

dotnet --list-runtimes

如果使用自包含部署（Self-contained）或 NativeAOT，还需要检查实际发布产物，因为更新服务器上的共享运行时不会自动替换已经打包进入应用的旧代码。

5。 检查容器镜像

如果应用运行在 Docker 中，应进入容器检查实际运行环境：

docker exec -it <container_name> sh

随后根据应用类型执行：

node -v
python -m pip show Brotli
dotnet --list-runtimes

这些命令需要按照容器内实际安装的运行时选择。

对于多阶段构建镜像，还需要检查最终运行镜像中的依赖，而非仅检查构建环境。

六、修复方案

1。 优先更新 Brotli 库

Google Brotli 官方已经发布三个安全修复版本：

• 1。0。10
• 1。1。1
• 1。2。1

对于新项目，建议优先采用当前受支持的安全版本。

官方代码及发布记录：

• github：google/brotli
• github：google/brotli/releases/tag/v1。2。1

2。 更新 Python 依赖

使用 PyPI Brotli 的项目可以执行：

python -m pip install --upgrade "Brotli>=1。2。1"

使用 brotlicffi：

python -m pip install --upgrade "brotlicffi>=1。2。1。0"

更新后重新执行依赖检查和应用测试，并确保生产环境使用了更新后的依赖。

3。 更新 Nodejs

Nodejs 用户应从官网安装对应维护分支的安全版本。

建议版本：

Nodejs 22。x >= 22。23。4
Nodejs 24。x >= 24。22。2
Nodejs 26。x >= 26。12。1

对于已经结束维护的版本，应升级到仍获得安全支持的分支。

如果使用 Docker，建议更新基础镜像后重新构建并部署应用。

例如：

FROM node：24。22。2-alpine

WORKDIR /app

COPY package*。json 。/

RUN npm ci --omit=dev

COPY 。 。

CMD ["node", "server。js"]

示例仅展示基础镜像更新方式。正式部署时还应确认所用镜像标签及底层 Alpine 软件包已经包含相应补丁。

4。 暂时无法升级时如何缓解？

如果因为兼容性问题无法立即更新，可以考虑以下措施。

第一，限制不可信 Brotli 输入。

对于接收外部 HTTP 请求的服务，可以在 API 网关、反向代理或应用入口拒绝带有以下请求头的压缩请求体：

Content-Encoding： br

前提是确认后端业务确实依赖该请求头进行 Brotli 解压。

第二，检查自动解压功能。

例如 。NET 开发者可以检查现有 HttpClient 配置是否开启了：

DecompressionMethods。Brotli

如果当前业务确实开启了自动 Brotli 解压，可暂时调整为仅允许其他受支持的压缩方式。

第三，降低应用进程权限。

为服务配置最小权限账户，限制文件系统访问能力，并结合容器隔离、SELinux、AppArmor 等机制降低成功利用后的危害。

第四，加强异常行为监控。

关注异常 Brotli 请求、进程崩溃、异常子进程及可疑出站连接。

但需要注意，WAF 规则、进程隔离与禁用部分解压路径只能作为临时缓解措施，最终仍应完成补丁升级。

七、总结

CVE-2026-111497 最值得关注的地方有三个。

首先，漏洞产生于广泛使用的底层压缩库。一次解码器实现错误，就可能影响 Nodejs、Python、。NET 和多个基础设施产品。

其次，漏洞根源在于错误状态处理和缓冲区边界检查失效。一个没有得到正确处理的异常返回值，最终可能发展为严重的内存破坏问题。

最后，这个漏洞已经出现公开 PoC，并被 CISA 列入 KEV，说明风险已经进入实际攻击阶段。

对于开发者和服务器管理员，建议优先完成以下工作：

1。 检查应用是否使用受影响的 Brotli 解码器。
2。 确认外部不可信数据能否进入解压流程。
3。 更新 Brotli、Nodejs、Python 或 。NET 相关组件。
4。 重新构建并部署包含受影响依赖的容器和应用。
5。 对公网服务检查异常请求与潜在入侵迹象。

对于此类底层依赖漏洞，最容易被忽略的风险往往藏在第三方库、运行时和容器镜像中。

即使业务代码从未直接调用 Brotli，底层依赖也可能已经将其引入系统。

因此，完善软件依赖清单、及时更新运行环境，并了解外部数据实际经过哪些解析组件，是降低类似供应链安全风险的有效措施。