Node.js 高危漏洞升级前，先分清三个修复版本

先运行 node -v，22.x、24.x、26.x 应分别以 22.23.4、24.22.1、26.12.1 为本轮升级目标；这是 Node.js 在 2026 年 10 月这一安全批次给出的三个修复版本，同步修复 10 余个漏洞，其中 4 个被评为高危。本轮最值得重视的是 Brotli 解码器越界写入可导致远程代码执行，而 DNS 解析中 NUL 字符截断、全角数字 IP 绕过 TLS 主机名验证、宽松解析的 IP 主机名绕过同样被列为高危。升级之前先把本机、服务器、容器、CI 里究竟在跑哪条分支的哪个版本查清楚，比直接下载新安装包更重要；线上跑着旧二进制、只把开发终端升上去，是这一类安全升级最常见的盲区。

这三个修复版本只覆盖 22.x、24.x、26.x 三条发布线。20.x 与更早的发布线并没有出现在本轮修复清单中，如果你的项目还停留在 18.x 或 20.x，套用本轮版本号是错的。换句话说，这一轮安全更新并不是面向所有 Node.js 用户的，而只覆盖当前仍在维护的三条线；剩下的事情，要么等更早批次的修复，要么规划跨主版本迁移。

先查实际运行的版本

在每台机器、每个容器、每条 CI 流水线里执行 node -v，并用下面的命令确认运行时版本和可执行文件路径：

node -p process.versions.node
which node

which node 反映 PATH 中找到的二进制，node -p process.versions.node 反映该命令启动的进程实际加载的运行时。多版本管理器场景下，应结合两项结果确认实际版本。服务器上如果同时装了 nvm、n、fnm 或 system node，还要用上面的命令看 PATH 中实际加载的是哪一份，shell 启动脚本可能把你切到一个并不期望的版本。

容器场景应检查镜像和容器内实际运行的 Node.js，不能只看宿主机。可以通过以下命令检查镜像中的版本：

docker run <image> node -v

如果项目里用了多阶段构建，CI 里的构建阶段与运行时阶段要分别确认。开发机升级完了而构建镜像还是旧的，是这一类升级最容易漏的环节。

按分支匹配修复版本

确认分支后，把目标版本锁死：

这是同一安全批次的三个修复版本，缺哪个补哪个，不要跨分支错配：把 24.x 升到 22.23.4 会出现 ABI 不兼容，反之亦然。20.x 与更早的发布线本轮没有给出对应版本号，需要单独查更早的批次或官方公告，不能用 22.23.4 / 24.22.1 / 26.12.1 顶替。

参考资料里有一篇转述把更新主线写成”6.x、24.x、22.x”，但同一篇详细清单中给出的版本号 v26.12.1 以及另一份资料 都明确指向 26.x。正式升级前应以官方安全公告再核验一次，避免把”6.x”这种印刷或转写错误当作发布线。

DNS 输入先做负例测试

四个高危漏洞里，CVE-2026-105482 落在 dns.resolve() 家族：传入含 NUL 字符（\x00）的域名时，域名会被截断，导致后续解析行为与调用方预期不一致；该漏洞影响 26.x、24.x、22.x 三条发布线，所以不论你跑哪条分支都要查。

排查时重点看用户可控的域名来源：HTTP 反向代理的 Host 头、自定义转发接口、邮件解析服务、子域名批量校验、URL 解析后的 host 抽取。NUL 字符通常不会出现在合法 DNS 域名里，但若上游输入来自 JSON、二进制协议或拼接过的字符串，就可能在交给解析器前混入 NUL 字符。修复前的临时做法是在调用 dns.resolve 之前用白名单拒绝含 NUL 的输入，例如：

if (host.includes('\x00')) {
  throw new Error('invalid host');
}

这只能缩小触发面，不能替代补丁；根因在 dns.resolve 的内部截断逻辑。

TLS 主机名必须严格比对

本轮两个高危漏洞都涉及 TLS 证书主机名验证。CVE-2026-105483 影响 26.x 和 24.x：当主机被写成全角数字形式时，可绕过基于 ASCII 数字的 IP 校验逻辑。CVE-2026-106069 同样影响 26.x 和 24.x：当主机名通过宽松解析被解析为 IP 时，也能绕过验证。两个漏洞的共同特征是：字符串到 IP 的转换在某个环节走了与 TLS 校验不同的路径，让”看起来是主机名、解析后是 IP”成为可行的绕过方式。

排查时关注三类调用：自定义的 tls.connect({ host, servername })、自己实现的 HTTPS 客户端（特别是没走 https.request 而是直接构造 socket 的代码）、任何对 URL 字符串做了 new URL() 解析后再 lookup 的转发代理。配合资料中提到的中危问题 CVE-2026-106072（非规范 IPv4 主机名验证不正确），建议在测试里同时准备全角数字 IP、宽松解析结果、压缩/展开形式的 IPv4 字符串三类负例，分别看客户端是否会拒绝证书。

Brotli 压缩流必须隔离

四个高危里影响最大的是 CVE-2026-111497：Brotli 解码器在特定条件下发生越界写入，并可被利用为远程代码执行。修复这个问题的版本随本轮三个修复版本同步发布。

排查要找的是”接收外部 Brotli 流的入口”：HTTP 客户端开启 Accept-Encoding: br 后收到的响应体、上传接口接受 Brotli 压缩文件、网关或反代对请求体做预解压、构建链里使用 Brotli 的工具。攻击向量不只来自网络，文件中转、备份还原、消息队列里被压缩的载荷同样属于”不可信输入”。升级到 22.23.4 / 24.22.1 / 26.12.1 之前，临时做法是把解压放到独立子进程（崩溃不影响主服务）、对异常压缩流直接丢弃并记录、限制单次解压的输入大小。这些措施不能替代补丁，但能减少被利用成 RCE 的窗口。

套接字复用要验证响应时序

CVE-2026-105481 是中危：keep-alive 套接字在请求发送前就已写入响应时，处理逻辑会出现错位。这类问题不会直接造成数据泄露，但会破坏协议假设，可能让请求与响应错配，严重时还能用来污染后续连接。

排查时关注长连接客户端：HTTP keep-alive 池、数据库连接复用、自定义二进制协议客户端、反向代理软件。复现路径是把同一连接并发复用，构造出”先收到响应、对应请求后发出”的时序。普通请求测试不易触发，需要结合超时与连接池的极端参数；Nagle 算法、TCP_NODELAY 开关、客户端的 socket buffer 大小都会影响触发概率。

快照与 ZIP 输入要单独回归

本轮还有两个中低危问题需要单独回归：一个涉及启动快照中的随机值，另一个涉及 ZIP 文件头校验。CVE-2026-106074 是中危：crypto.randomUUID() 与 randomInt() 的熵缓存被保存进用户态启动快照和 SEA 工具产出的二进制中，导致每个进程重复生成相同值。如果你的服务在启动时依赖 UUID 做去重、做请求 ID、做文件名生成，这种”每个进程都生成同一个值”会让所有节点看上去是同一个客户端。SEA 产出的可执行文件同样会受影响：启动两次的产物随机值是同一个。

CVE-2026-106070 是低危：ZipFile 在 ZIP 文件头验证失败后仍会返回攻击者控制的前缀字节，属于信息泄露的小窗口。回归测试要分别覆盖：启动快照 / SEA 产物中进程启动后的随机值是否跨进程保持不同，以及畸形 ZIP 文件头不会暴露攻击者可控的内容。这两项都不是 node -v 能验证的，必须跑实际业务。

文件权限要验证真实路径

两个低危都涉及 Node.js 的权限模型。CVE-2026-106071：通配符基数查找会授予过多文件系统权限。CVE-2026-106073：fs.realpathSync() 可绕过权限模型。这两条针对的是启用 Node.js 权限模型后的场景，下面的命令用于启用该模型：

node --experimental-permission

如果你的服务没有启用权限模型，它们不构成直接风险。

如果启用了权限模型，回归测试要把通配符规则和符号链接场景都跑一遍，特别是依赖解析、临时文件、缓存目录这类路径会随运行动态变化的场景。fs.realpathSync 在符号链接被拼接进允许路径时是常见的绕过路径，需要专门构造测试用例。

升级前保留可回退基线

动手之前，把现有产物留一份：当前 node 二进制路径、容器镜像 digest、package-lock.json / pnpm-lock.yaml / yarn.lock、原生模块（node-gyp 编译产物）的版本快照、关键进程的 systemd / supervisor unit 文件。回退基线不是 git revert 那样简单——Node.js 主版本变更可能让原生模块编译失败、CI 缓存里残留旧 binding。

测试环境先走一遍完整升级：用目标版本重新安装依赖（必要时执行下面的命令），跑完业务回归再考虑生产替换。

rm -rf node_modules && npm ci

原生模块（better-sqlite3、canvas、node-sass、bcrypt 等）在主版本变更后大概率要重编，提前确认目标版本对应的 Node-API 版本能编译过。

同分支升级按顺序执行

升级时按以下顺序执行：先装新版本、确认 node -v 输出目标号、重新构建依赖、跑测试、替换运行实例、重启所有长驻进程。每一步完成后再进入下一步，不要试图”装完直接重启生产”：一旦新版本与原生模块不兼容，回滚的时间窗口会很紧。

系统包管理（apt、yum、brew、scoop）安装的 Node.js 用包管理器自身的命令升级；nvm / fnm 这类版本管理器用其内置安装命令切到目标版本；源码安装则重新拉取并编译。无论用哪种方式，升级完后用下面的命令确认 shell 从 PATH 找到的就是新二进制，而不是某个被遗忘的旧路径：

which node

容器与 CI 必须重建镜像

基础镜像只声明 node:22、node:24、node:26 并不够：这些 tag 默认指向 latest，可能仍是本轮修复前的旧层。应显式固定到 22.23.4、24.22.1、26.12.1 这样的精确版本，或者用 digest 而不是 tag。多阶段构建里如果某一层缓存了 node_modules，升级后要把构建缓存清掉再重跑。

CI 同理。GitHub Actions、GitLab CI、CircleCI 的 runner 镜像如果是项目自己构建的，重建并重新打 tag；如果用的是托管镜像，确认该镜像已经在本轮之后更新过。Pull request 流程中跑构建时，CI 缓存里残留的旧 Node.js 是最容易漏的环节。即使构建机已经升级，CI 缓存拉出的 node_modules 仍可能包含旧 binding。

升级后验证真实进程

node -v 输出版本号只是第一步。实际验证要在应用进程里读出 process.versions.node 并写进日志或健康检查接口，这样能区分”开发机升级了”和”线上进程真的在跑新版本”。集群部署里要逐节点验证，负载均衡后面的实例可能仍是旧二进制。

复测时把前面列过的负例再跑一遍：含 NUL 字符的域名、全角数字 IP、宽松解析主机名、畸形 Brotli 流、畸形 ZIP、并发 keep-alive 时序、通配符权限规则、符号链接绕过。修复前应能触发问题，或至少由测试用例检出；修复后则不应再触发。这一步比版本号更能验证升级是否到位。

暂时不能升级先缩小暴露

业务节奏不允许立即升级时，先做四件事：对来自用户输入或第三方接口的域名做白名单校验，并拒绝 NUL 字符；对 TLS 主机名禁用宽松解析、显式比较 IP 字面量；外部 Brotli 与 ZIP 输入用独立子进程处理并限制输入大小；在生产环境关闭权限模型的通配符，回到显式路径授予。这些措施不能替代补丁，但在补丁落地前能把暴露面压到最小。每一项都应当有日志佐证，证明触发确实被拦截，而不是悄悄放行。

版本结论以官方矩阵为准

本轮资料里没有给出 20.x 与更早发布线对应的修复版本，20.x 用户不能直接套用 22.23.4 / 24.22.1 / 26.12.1；同样，资料中同一篇转述既把主线写成”6.x”，又在详细清单中给出 v26.12.1，另一份资料 则指向 26.x。正式落地前以 Node.js 官方安全公告为准。跨主版本迁移（特别是从 20.x 跳到 22.x）涉及 Node.js 行为变更、原生模块重编译、依赖兼容性回归，需要单独规划，不能塞进”打补丁”这一次动作里完成。

正式实施升级时，应核对 Node.js 官方博客与 GitHub Security Advisories 中三条发布线的安全公告，把”4 个高危 + 6 个中低危”完整核对一遍。资料的转述可能滞后于官方版本，DNS / TLS 两类高危漏洞应优先处理。