node.js 2026年10月21日发布官方安全更新，覆盖22.x、24.x、26.x三条仍在维护的分支，共修复10项漏洞，其中4项高危、3项中危、3项低危。其中一项高危漏洞为cve-2026-111497，对应brotli解码器远程代码执行问题，其余问题涉及dns域名截断、tls主机名验证、随机数缓存和权限模型等场景。
这批漏洞全部位于Node.js运行时内置代码及自带依赖中。开发者单独运行npm update或执行npm audit fix，只会更新项目依赖的第三方包，不会替换操作系统或部署环境里的Node.js可执行文件。升级必须落到服务进程实际调用的运行时版本，以及对应的部署镜像。
本次更新覆盖的全部漏洞
Node.js 官方安全公告列出了所有待修复问题，不同版本分支的受影响范围并不完全一致，开发者要对照自己在用的具体版本核对。
| CVE | 问题 | 严重度 | 公告列出的分支 |
|---|---|---|---|
| CVE-2026-105482 | DNS 名称中的 NUL 字符导致截断 | 高 | 22、24、26 |
| CVE-2026-105483 | 全角数字 IP 的 TLS 主机名验证绕过 | 高 | 24、26 |
| CVE-2026-106069 | 宽松解析为 IP 的主机名绕过 TLS 验证 | 高 | 22、24、26 |
| CVE-2026-111497 | Brotli 解码器越界写入，可导致 RCE | 高 | 22、24、26 |
| CVE-2026-105481 | Keep-alive 连接处理请求发送前的响应 | 中 | 22、24、26 |
| CVE-2026-106072 | 非规范 IPv4 主机名的证书校验问题 | 中 | 22、24、26 |
| CVE-2026-106074 | 启动快照和 SEA 保存随机数缓存 | 中 | 22、24、26 |
| CVE-2026-106070 | ZIP 头校验失败后返回攻击者控制的前缀 | 低 | 26 |
| CVE-2026-106071 | 权限模型通配符查找导致授权过宽 | 低 | 26 |
| CVE-2026-106073 | fs.realpathSync 的权限模型绕过 | 低 | 22、24、26 |
Brotli RCE漏洞为什么必须升级Node本体
Brotli是通用无损压缩格式，Node.js内置的原生解码模块专门处理这类压缩数据。如果业务需要直接解析来源不可信的Brotli格式数据，就需要关注这条解码路径的风险。这个漏洞的触发条件和应用、第三方客户端库的实际行为有关，不会出现在所有业务场景里，也不能只靠检查package.json有没有声明brotli依赖判断是否受影响。
在Node.js 24.22.1 发布记录中，Brotli 官方修复提交修改了 deps/brotli/c/dec/decode.c 等底层源码文件，调整了解码过程的错误返回逻辑和状态校验流程，开发者不可能仅在业务JavaScript代码里加try/catch就完成修复。
业务侧设置响应体大小上限、控制并发解压任务数、限制解压后数据体积，只能缓解资源消耗类风险，不能完全覆盖原生解码器的越界写入问题。自行维护定制Node.js构建的团队，建议直接采用官方完整安全发行版，不要单独替换单个依赖文件，避免内部版本逻辑不一致。
DNS与TLS校验的修复逻辑说明
DNS 修复提交 843a1627把原有入口的普通字符串检查，替换成主动拦截NUL字符的校验逻辑，下面是该提交的局部diff，用来展示校验规则的变化：
<code class="diff">- validateString(name, 'name'); + validateStringWithoutNullBytes(name, 'name');</code>
这段校验逻辑属于Node.js内部函数，不能直接复制粘贴到业务代码里当作完整补丁。官方提交同时覆盖了回调风格和Promise风格的相关DNS入口，采用完整修复版运行时，可以更新这些内置校验路径。
TLS相关的官方提交 935918e3，新增了针对主机名、ASCII归一化形式与IP解析结果不一致场景的拦截逻辑。如果你的业务自定义了 checkServerIdentity 方法，要确认没有跳过标准的主机名验证流程，具体接口规则可以参考 Node.js TLS 文档。
官方修复版本与安装源说明
本次安全更新对应的修复版本分别是 22.23.4、24.22.1、26.12.1，对应22、24、26三个维护分支。你可以直接升级到对应分支的修复版，或者后续包含该补丁的受支持版本，不需要跨分支直接挑大版本号最高的安装。
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
官方发布页分别提供了22.23.4、24.22.1、26.12.1的安装包和校验信息。如果你用的是系统软件源、版本管理工具或者第三方厂商打包的Node.js，要确认实际安装的版本已经包含这次的补丁。已经停止维护的旧分支建议尽快迁移，不要仅凭公告没提到旧分支就默认它不受影响。
终端显示版本已更新但服务仍跑旧版的常见原因
不同用户的环境变量PATH、PM2的解释器配置、systemd的ExecStart参数、容器镜像里预装的运行时，都可能指向不同版本的Node.js。下面的命令只能反映当前执行命令的终端环境，不代表所有正在运行的服务实例：
<code class="bash">node --version node -p 'process.execPath' node -p 'JSON.stringify(process.versions, null, 2)'</code>
你可以在应用启动代码里打印进程的运行时信息，结合重启后的日志确认实际调用版本。下面是常用的JavaScript示例，全程不需要关闭任何安全校验选项：
<code class="javascript">console.info(JSON.stringify({
event: 'runtime-start',
pid: process.pid,
node: process.version,
executable: process.execPath,
brotli: process.versions.brotli
}));</code>
部分下游维护团队会单独给Brotli依赖打补丁但不改动版本号，所以不能仅靠第三方依赖的版本字符串判断漏洞是否修复，必须对照Node.js官方的发行说明确认。运行时更新完成后，一定要重启实际运行的服务进程。如果项目用到了原生npm扩展，要在新版Node.js环境里重新安装构建，避免旧产物出现兼容性问题。
Docker环境下的Node.js升级步骤
下面的示例适用于带package-lock.json、直接用node启动server.js的普通JavaScript项目。如果你的项目涉及TypeScript编译、前端构建等自定义流程，要保留原有构建逻辑不变。
<code class="dockerfile">FROM node:24.22.1 WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci --omit=dev COPY --chown=node:node . . USER node CMD ["node", "server.js"]</code>
在项目根目录新增下面的.dockerignore文件，可以避免把宿主机上的node_modules目录直接复制到镜像里，覆盖镜像内安装的依赖版本：
<code class="text">node_modules .git npm-debug.log</code>
<code class="bash">docker build --pull --no-cache -t my-node-app:security . docker run --rm my-node-app:security node --version</code>
新镜像构建完成后，你需要按自己的部署平台替换掉正在运行的旧容器。只在宿主机执行docker pull拉取新镜像，或者直接重启基于旧镜像启动的容器，都不会修改容器内预装的Node.js二进制文件。
升级后HTTPS连接失败的处理方法
遇到连接报错时，先排查四类常见原因：证书链本身不可信、域名和证书绑定信息不匹配、非规范IP地址格式，以及业务自行实现的校验逻辑存在问题。这次安全更新调整了部分证书信任相关规则，旧连接方式被拒绝可能是安全校验收紧后的预期行为，仍需根据具体错误判断原因。
不要用设置 NODE_TLS_REJECT_UNAUTHORIZED=0、把代码里的rejectUnauthorized设为false、或者直接让checkServerIdentity永远返回成功的方式绕过报错。要修正证书链配置、规范目标访问地址，保留系统默认的标准验证逻辑。Node.js运行时更新和业务层输入校验需要同步维护，npm包漏洞扫描只是安全保障的其中一部分。
