容器镜像中的旧版Node.js如何排查?

容器镜像里的 Node.js 版本，最容易误判的地方往往就在标签上。Dockerfile 写的是某个版本线的基础镜像，只代表构建起点；多阶段构建的后半段、后续层里通过包管理器或全局安装带入的运行时，都可能让最终镜像中的实际版本与标签不一致。因此，排查的第一步应当是对已构建完成的镜像本身做核对，而不是阅读构建脚本：进入容器执行 node --version，确认解析到的路径就是预期的那一份，而不是某个工具自带的私有副本。

这次 Node.js 22.23.4、24.22.1、26.12.1 三条版本线的更新，恰好说明了为什么这种核对不能省略。CVE-2026-111497 是捆绑的 Brotli 解码器中的越界写入缺陷，风险不止落在直接调用压缩接口的代码上；框架、中间件、代理组件中隐式启用解压的路径同样可能被触及。同批更新还修复了两个 TLS 主机名验证绕过问题（CVE-2026-105482、CVE-2026-105483）。判断是否暴露，依据只能是镜像内实际运行的版本。

排查范围应当覆盖镜像的构成，而不只是主进程。列举镜像内所有 Node 二进制、检查包管理器的安装记录、确认是否存在多份来源不同的运行时共存，都是必要动作。CI 环节同样要查：缓存了 Node 二进制或依赖安装产物的流水线，可能在“重新构建”时把旧版本原样带回镜像，构建日志和缓存键比标签更可靠。Serverless 的运行时层、开发机上的全局命令行工具也可能捆绑独立的 Node.js；资料中提到 Bun 等运行时同样捆绑了解码组件，但这类判断应以对应项目的官方公告和实际版本核对为准，不能仅凭“用了 Brotli”推定受影响。

对仍停留在 Node.js 20 及更早版本的镜像，盘点结果应直接标记为迁移对象。这些版本线已不再提供修复，边界层限制不可信 Brotli 数据入口只能短期降低暴露，替代不了补丁。

升级之后要重新构建全部相关镜像与制品，并留下可复核的证据：运行时版本、镜像内版本、解压路径的回归测试，以及 TLS 主机名验证相关连接的检查。回滚应以镜像摘要为锚点而非标签，否则容易出现应用已回滚、基础镜像仍是新版这类不一致状态。