2026年10月21日，Node.js为还在维护的三条版本线一次性发出安全更新：22.x、24.x、26.x，对应的修复版本分别为22.23.4、24.22.1、26.12.1，官方列出的最高严重级别为High。这一批修掉10项漏洞：4项高危、3项中危、3项低危，风险类型包括远程代码执行、TLS证书校验绕过、DNS解析异常等。知乎知乎
先说定心的部分：这次的修复全部落在同一大版本线的补丁版本里，官方没有重排API，也没有逼任何人换大版本。只要业务跑在22、24、26上，升级本身的成本几乎为零。真正对得起"不炸项目"四个字的，是升级后那几类行为变化，以及升不到补丁的20.x和25.x用户。
先确认：你有没有在射程内
还停在22.x、24.x、26.x的，直接升到上面那三个精确版本号。20.x已在2026年4月30日停止维护，25.x在6月1日停止维护，这次都没有补丁，官方同时提醒：停止维护的版本每轮安全更新都会受影响，还在用的只能换到22、24或26。另一个容易误解的点是：在机器上装好新版本，不等于项目都切过去了——升完要逐个查一遍实际运行的Node版本，再确认业务正常。微博知乎
修了什么，坏在哪
四项高危里，第一个是内置Brotli解码器（CVE-2026-111497）的越界写：官方定性为可导致远程代码执行，评级high。Brotli是网页传输里常用的压缩格式，HTTP里写作`br`；公告对它只有这一句描述，没有说什么情况下会触发，修法是同步了Google Brotli项目的上游改动，让解压程序更早发现并拒绝格式不对的数据。触发条件未公开，意味着没人能靠"对照配置"自证不受影响——凡是暴露在公网、会解压外部输入的Node服务，都应按急需处理对待。知乎微博
另一项高危在`dns.resolve`：域名中间夹着空字符（NUL）时，Node会在那里把名字截断，实际解析的只是前半截。剩下的还有HTTP keep-alive连接处理、证书校验、随机数缓存以及ZIP和权限模型等中低危问题，触发条件和后果各不相同，不能把整批更新概括成"Node都能被远程接管"。同一个安全版本里还带了c-ares、OpenSSL、Undici等依赖更新，顺带修掉这些组件已公开的漏洞。微博知乎知乎
还捎带了一件东西：证书黑名单
三个新版本都加了一份内置黑名单，第一批放进去的就是eMudhra那8枚出问题的中间证书——这些被各家系统认可的"网站公章"，盖章用的私钥小到一秒就能被算出来；10月17日被发现后，Chrome和Firefox当天拉黑，Apple、Microsoft相继跟进，Node.js在21日发版补上。微博
关键在机制：Node一直内置Mozilla的可信根列表，却没有浏览器那种随时拉黑坏证书的机制，旧版对这批假证书照样放行，这份黑名单补的就是这个缺口。 如果你的站点证书链恰好经过这批证书签发，新版Node的出站连接会开始拒绝它——升级前先核对证书签发方。微博
升级后"炸"的，大多是修复在起效
第一类炸点是TLS变严。本轮TLS问题集中在IP写法上：全角数字的IP，或者写法不规范但能被宽松认成IP的地址，都可能绕过主机名校验；修复后Node直接拒绝不规范的IP写法，全角数字问题只影响24.x和26.x。原来"侥幸能连上"的脚本、内部服务突然握手失败，先别急着回滚——那多半是旧的绕过被堵上了，改的是地址写法或证书配置。微博
第二类是内置组件的行为差异。c-ares、OpenSSL、Undici随版本一起更新，补丁号不等于上游行为零变化。社区里有过现成的教训：有开发者换用高版本Node后，底层OpenSSL屏蔽了一个低版本RSA加密方法，项目的加密解密直接出错，前后端都被迫跟着改。微博
第三类是打包要重来。用启动快照或SEA单文件打包的项目，`crypto.randomUUID()`和`randomInt()`的随机缓存会被一起打进包里，每次启动生成同样的"随机"值；升版本后必须重新构建产物，否则跑的还是旧的解码器和旧的随机缓存。微博
紧急修复六步
盘点：别只看本机`node -v`，要确认容器、进程管理器、云函数里实际运行的版本，而不只是本地开发环境的版本。知乎
升到位：同线升级到那三个精确版本；生产环境的老规矩是优先选仍在维护的LTS版本，升级前先做兼容性验证。知乎
重建并重启：升级后检查容器是否重新构建、进程管理器是否重启、云函数运行时是否切换；开发机更新了而生产容器未重建，等于没修。知乎
回归：重点跑一遍对外HTTPS集成、DNS解析、压缩路径、随机数和加解密相关的链路。
回滚预案：保留旧镜像标签备短时间急用；但回滚等于回到暴露状态，确要回滚就配合访问控制或网络隔离，并尽快回到修复版本。
事后排查：升级前服务曾长期暴露在公网、出现过进程异常重启或可疑外联的，按安全事件处理，访问日志、异常文件、凭据逐项过一遍。
补上一步的原因：打补丁只防住后续利用，清除不了攻击者此前留下的东西——访问日志、异常进程和被盗凭据，补丁不会自动替你处理。知乎
卡在20.x或25.x：唯一的出路是搬家
这三个线之外的版本没有补丁，修复只有一条路——跨大版本迁移到22、24或26。"炸项目"的经典风险恰恰在跨大版本：依赖的engines要求对不上、原生模块要重新编译、行为差异要逐个回归。哪怕暂时迁不动，也不能假设停止维护的旧版本是安全的。 先收窄它的对外暴露面、加访问控制，把隔离做在今晚；迁移排上日程后，用nvm或`.nvmrc`按项目管版本、一次只动一个项目，避免"老项目升级之后出现兼容性问题"时牵连一片。知乎知乎
为什么别再"等炸了再修"：同一轮PHP漏洞里，补丁刚正式发布，安全厂商就预警大规模扫描会在15分钟内开始。跟进这轮公告的厂商运维团队也感叹，以前一个洞从披露到野外利用可能有几周窗口，现在这个窗口在肉眼可见地缩短。对Node.js来说，最省事的姿势不是等出问题再排障，而是让业务始终停在官方安全维护期内的线上：升级炸了，炸出来的通常是配置层面的错误，能排查；漏洞被利用，炸出来的就是事故。知乎知乎
