Node.js 10 月安全版本：开发者需要完成的四件事

这次发布了什么

Node.js 项目已于 2026 年 10 月 21 日（周三）当天或稍晚，发布了 26.x、24.x、22.x 三条版本线的安全版本。三条线本次的最高严重级别均为 High（高危）。

按官方公告列出的条目，本次修复涵盖以下几类问题。下面只描述问题的性质与影响面，不涉及触发方式：

除上述条目外，本次发布还同步了一批依赖库的更新：c-ares、ca-cert（涉及一批不再受信的中间证书调整）、OpenSSL、SQLite、Undici 等。OpenSSL 与 SQLite 的更新只在部分版本线上提供，具体以官方公告中的版本线对照为准。

需要特别留意的是：Node.js 16、18、19、20、21、23、25 等版本线已经结束生命周期，本次不会获得任何修复。仍在 EOL 版本上的服务，处理方式不是等待补丁，而是迁移到仍在支持期的版本线。

需要完成的四件事

第一件：把实际在跑的版本全部查清楚

开发机、构建机、测试机、生产容器里可能装了不同版本，凭印象判断容易漏。建议按「进程」与「容器镜像」两层各查一遍。

# 当前命令行版本
node -v

# 查看版本管理器下的多个版本（以 nvm 为例）
nvm ls

# 容器场景：列出镜像与其中运行的 Node 版本
docker ps --format "{{.Image}}"
docker exec 容器名 node -v

# Linux 上列出所有可执行文件位置
which -a node

如果使用了 Serverless 或云函数类服务，还要留意服务商自己的说明——托管平台通常会统一替换运行时底座，但替换时间不一定与官方同步。

第二件：升级到对应版本线的修复版本

修复版本在三条版本线各自的最新安全版本上，具体版本号请以官方安全公告为准；生产环境升级前，建议先在测试环境完成兼容性验证并保留回滚方案。

需要区分两种情况：

• 还在支持期的版本线：升级到该版本线新的安全版本即可，属于小版本更新，通常改动可控。
• 已在 EOL 的版本线：没有可用补丁。且跨大版本迁移会遇到 API 变化、依赖兼容性等问题，应当单独排期，而不是临时跳过。

Node.js 项目在 GitHub 上的安全受理流程与 nodejs-sec 邮件列表，是获取这类信息的低干扰渠道，建议团队里至少有一个人订阅。

第三件：重新构建与重新部署，而不只是换版本号

Node.js 是运行时，它被打包进镜像和制品里。只更新流水线上的安装脚本，已经构建好的镜像不会自动改变。需要按下面顺序走：

1. 更新基础镜像或版本锁定文件；
2. 重新构建镜像，并把依赖一并重装，避免缓存住旧的二进制；
3. 部署后重启进程——这一点尤其重要，运行中的旧进程不会因为磁盘上的文件被替换而自动切换版本；
4. 验证：node -v 输出与预期一致，且服务启动日志无异常。

第四件：顺手复核依赖与构建链

本次发布包含多处依赖更新，说明依赖本身也处在持续变动中。可以借这次机会做一次常规体检：

• 用包管理器的审计命令查看已知有问题的依赖（npm audit / pnpm audit 等），把它当作参考输入，实际是否受影响仍需结合依赖关系判断；
• 检查锁文件是否真的锁住了版本，避免不同环境装出不同结果；
• 把「运行时版本」纳入资产清单，覆盖版本管理器、容器基础镜像、CI 镜像三处。

一个常见的误判

有开发者认为「我的服务在内网、不直接对外」就不受影响。但本次涉及 Brotli 解码与 TLS 校验的问题，影响范围取决于服务是否处理外部输入——只要存在接收外部数据的通道（HTTP 接口、反向代理转发、第三方回调等），就值得按公告完成升级。

排优先级时可以参考这个顺序：先处理面向公网的服务、处理不可信输入的接口，以及与其他系统有大量 TLS 通信的组件。

运行环境建议统一管理

运行时版本建议尽量统一，避免一台机器上散落多个来路不明的安装，这在接到安全通报时能省下大量排查时间：

• Docker Desktop：容器化环境，便于隔离不同项目的运行时版本
• Visual Studio Code：跨平台编辑器，可在项目内约定 Node 版本，减少环境差异
• Git：版本控制，配合锁文件管理依赖版本的常用组合