Node.js 11 月 11 日发安全版本：26、24、22 三条线全标 HIGH，而且现在还不知道 CVE 编号

Node.js 发安全版本前会先贴一张「预告」，只写严重等级、影响版本线和发布日期，不写漏洞细节。11 月这一张写的是：11 月 11 日（周三），26.x / 24.x / 22.x 三条线同时发，最高等级都是 HIGH。

现在是 8 号。也就是说，你有三天。

三条线全是 HIGH 意味着什么

以往这种预告经常是一条线 HIGH、另两条线中低，因为老版本里该修的已经修完了。这次三条线一致，说明问题出在三条线共有的代码里 —— 要么是 HTTP 解析、要么是 TLS、要么是某个大家都还在用的内置模块。

我不猜具体是什么模块，因为在没有细节的情况下猜，只会让人把注意力放在错的地方。值得记住的只有一件事：这类问题通常不需要你写任何业务代码就能被利用，一个暴露在公网的 Node 服务就是全部前提。

为什么「预告」比「公告」更有价值

漏洞公告发出来的时候，攻击者和你同时拿到信息。而预告给了你三天的准备时间，这三天能做很多事：

• 把各台机器的 Node 版本盘一遍（我发现过一台写着 22、实际跑着 18 的机器）
• 把升级脚本先跑一次 dry-run，确认没有原生模块要重新编译
• 想清楚哪个服务可以立刻重启、哪个必须等窗口
• 提前在预发环境升一遍，把「升完才发现某个包不兼容」这种事故挪到白天

这些动作的价值不在于「抢在攻击者前面」，而在于把一次被动应急变成一次有计划的变更。同样一个补丁，凌晨三点慌乱地打，和周三下午按流程打，风险差一个量级。

我的三天清单

我把这次当成一次小演练，具体做四件事：

1. 盘点：node -v 逐台确认，写进一张表。以实际二进制为准，不信文档。
2. 演练：在预发机上升一次，重点看原生模块（node-gyp 那类）会不会挂。挂了的，这几天先解决它的工具链。
3. 预留窗口：把周三晚上的变更窗口先占上。用不上没关系，用到时不用求人。
4. 别忘了 EOL 的那批：官方说得很直白，EOL 版本永远是受影响的，而且不会给它发补丁。你这周真正该动的是它。

顺便一提，如果你还在纠结升哪条线：26.x 刚转成 LTS（我写过那件事），24.x 也刚更新到 24.22.2。两条都在支持期内，选一条你能守三年的。

一句提醒

预告只说「on or shortly after」，意思是可能拖到周四。别把窗口卡死在周三深夜，给自己留一天余量 —— 我因为把「on or shortly after」读成「一定按时」，空守过一个通宵。