fix-node-vuln

修复 Node.js 漏洞（2026 年 10 月 21 日安全更新，包含 CVE-2026-111497）

概述

查找并修复受 2026 年 10 月 21 日安全更新影响的 Node.js 运行时。此次更新修复了 10 个 CVE，其中 4 个为高危漏洞，包括 Brotli 解码器越界写入导致的 RCE（CVE-2026-111497），以及 3 个 TLS/DNS 主机名问题（CVE-2026-105482、-105483、-106069）。修复版本为 22.23.4、24.22.1 和 26.12.1。Node 20 及更早版本已结束生命周期，不再获得修复，需要进行大版本升级。首先只读盘点。获得批准后再编辑。为每个获批的仓库打补丁，验证构建产物，并创建范围明确的 PR。

用户需要提供的内容

• 要扫描的仓库或组织。默认：用户指定的仓库，或 Agent 可访问的所有仓库。
• 批准要修补哪些已发现的仓库，以及是否将 EOL 大版本升级纳入范围。
• 验证目标版本并运行构建所需的注册表和 CI 访问权限。

流程

1. 在克隆之前，使用 Git 托管平台的代码搜索，以只读方式搜索所有可访问的仓库（如果没有代码搜索功能——GitHub Enterprise Server 和自托管 GitLab 上很常见——则进行浅克隆，并运行 rg -n --hidden --glob '!.git'，因为版本文件是点文件）。查找：
   • node: 和其他 Node 基础镜像，包括多阶段构建。
   • .nvmrc、.node-version、.tool-versions、Volta 配置，以及 actions/setup-node／CI 镜像。
   • NodeSource 或操作系统的 nodejs 软件包。
   • 无服务器运行时设置（Lambda nodejs22.x、Cloud Functions、Azure Functions）。
   • 安装 Node 的 Helm／Terraform／Ansible 代码。
   • 作为参考信号的 engines.node。
   • 已知目标主版本会导致问题的代码（例如导入断言 assert {、binding.gyp／node-gyp 中的原生附加组件、已移除的 API），以及仓库的测试命令，以便门禁检查能展示升级风险。
2. 生成一张清单表，列出：仓库、文件:行号、信号、当前版本、渠道、精确／浮动／摘要锁定、生产环境还是仅用于构建／CI、可判断时的互联网暴露情况、测试覆盖情况（无、有限、完整套件）以及置信度。另行列出无法搜索的仓库。
3. 将每个条目标记为已修复、存在漏洞、已停止支持或未知。对于发行版软件包和托管运行时，应查阅供应商的软件包变更日志或安全公告，而不是拿版本号与上游版本号比较。
4. 停止操作。展示表格并询问用户要修补哪些仓库。列出主版本升级可能涉及的应用代码变更，供用户预先审批。发现阶段不要做任何更改。
5. 按顺序逐个处理获批的仓库。如果 Agent 支持子 Agent，则每个仓库运行一个，最多同时运行五个。编辑前重新检查该仓库的清单。
6. 对每个仓库，为每条路径选择最小的已修复目标版本，并在编辑前确认该版本存在。若公共主机不可访问，应通过仓库 CI 已使用的注册表或软件包镜像（Artifactory、Nexus、Harbor 或云注册表）核实；若两者均无法访问，则在 PR 中将目标标记为未验证，并由 CI 构建确认。
   • 精确镜像标签：升级到同一主版本中的已修复补丁版本，并保留变体（-alpine、-slim、-bookworm 等）。
   • 摘要锁定：解析并锁定新的摘要。
   • 支持的主版本内的浮动标签：保留该标签。要求使用 --pull --no-cache 重新构建并重新部署，同时记录新摘要。对于获批的主版本升级，沿用仓库的锁定方式（浮动仍为浮动，精确仍为精确）。
   • 记录每个新镜像的多架构索引摘要，包括精确标签，因为操作系统层仍会变化。
   • 版本文件：设置为已修复补丁版本，并确保所有注明该版本的文件保持一致。
   • 使用浮动版本（22、lts/*）的 CI setup-node：添加 check-latest: true，或锁定到已修复补丁版本。否则会使用运行器缓存的旧版 Node。
   • 托管无服务器运行时（例如 Lambda nodejs22.x）：提供商不会公布精确补丁版本，因此应检查提供商的公共基础镜像（例如 public.ecr.aws/lambda/nodejs:22），或从函数记录 process.version。对于 Lambda 的 Auto runtime-update 模式，AWS 会就地更新，重新部署只是加快更新；对于 Function update 或 Manual 模式，则必须重新部署或更改运行时版本。
7. 除非 engines.node 会排除新版本（例如从 20 升级到 22 时仍设为 20.x，这会导致 npm ci 发出 EBADENGINE 警告），否则不要更改它。它不会安装任何东西。
8. 将 Node 20 及更早版本单独报告，并提供升级到 22 或 24 LTS 的路径。只有获得用户批准后才能进行主版本升级，然后执行第 9 步中的主版本升级检查。
9. 在更改前后测试回归：
   • 基线：编辑前，使用 --pull 构建当前镜像并记录其摘要（这是回滚目标）。在镜像内运行 npm ci／pnpm install --frozen-lockfile／yarn install --immutable、构建脚本（如有）以及测试。记录结果，以免将已有故障归咎于升级。
   • 更改后：在新的生产镜像内重复安装、构建和测试，而不是在主机上运行。如果该镜像不包含测试或开发依赖项（多阶段构建、--omit=dev），则使用相同基础镜像构建测试／构建阶段，或将测试挂载到生产镜像中。将新增故障和新增弃用警告视为回归。
   • 比较运行时：对比 node -p process.versions（V8、OpenSSL、ICU 等）以及新旧镜像的基础操作系统。对于会进行出站 TLS 调用（https、fetch、tls.connect）的服务，注明 eMudhra CA 已移除，以及 OpenSSL 默认设置更加严格。
   • 冒烟测试：使用生产命令启动容器，请求健康检查或主路由，并检查日志中是否有崩溃和警告。
   • 对于主版本升级（例如从 20 升到 22），还要使用 NODE_OPTIONS=--pending-deprecation 运行测试，从源码重新构建原生附加组件（npm rebuild），并列出适用的发行说明破坏性变更（例如 Node 22 移除了导入断言 assert { type: 'json' }，改用 with）。
   • 将每一步的输出保存为日志（基线、更改后、运行时差异、冒烟测试），并附到 PR 中。
   • 如果仓库没有测试或测试很少，应醒目说明，并提出最小冒烟测试或特征测试方案（未经批准不要提交）。
   • 确认已构建的生产镜像或运行时中的 node -v。
   • 如果出现回归，完成上述只读检查后停止，并附上失败输出和已在临时副本中验证的最小修复方案进行报告。版本升级改动保持未提交，等待用户决定。未经批准不要更改应用代码。
10. 为每个仓库单独创建一个聚焦的 PR，列出每条路径的升级前 → 升级后版本、摘要、需要重新构建的浮动标签、受阻项目、已停止支持的项目、基线与更改后的测试结果、运行时差异和验证证据。标注风险：同一基础镜像上的补丁版本升级为低风险；主版本升级、基础操作系统变更或未经测试的仓库为高风险；同时注明测试覆盖有限的情况。对于浮动标签，提供截至今天的摘要。附上发布计划：先部署到预发布环境或进行金丝雀发布，然后注明可回滚的上一版镜像摘要／版本。该回滚目标仍存在漏洞，因此仅短暂回滚。
11. 将各仓库结果汇总到一张表中：仓库、PR、路径、升级前 → 升级后、生产环境还是仅用于 CI、测试、受阻项目、后续事项。提醒用户，只有完成部署后修复才会生效。

规范

• 发现工作只读，并以明确的审批关卡结束。
• 编辑前确认每个目标都存在。
• 每个 PR 都要包含从构建后的生产制品中获取的 node -v 证据。对于仅用于 CI 的路径、版本文件和托管运行时，提供现有的最佳证据（安装程序或基础镜像解析出的版本），并说明用户合并后必须运行的检查。
• 完成意味着每个获批的部署都已验证修复，或已报告为受阻并附上明确的下一步操作。

建议和提示

• 优先处理面向互联网且会解压 Brotli 的服务（HTTP 客户端/服务器、代理、zlib.createBrotliDecompress）。也优先处理连接用户提供的主机的 TLS 客户端。
• 此次发布还会更新捆绑的 c-ares、OpenSSL（22/24）、SQLite（22）、Undici 和 CA 证书（移除 eMudhra）。
• Electron 应用、供应商镜像和设备会捆绑自己的 Node。请标记这些项目，要求供应商更新。
• 仅用于 CI 的 Node 优先级低于生产运行时，但如果修改成本较低，应在同一个 PR 中一并修补。

禁止操作

• 未经用户批准某个仓库，不得进行编辑。
• 不得猜测镜像标签、摘要或软件包版本。
• 未经明确批准，不得进行 Node 大版本升级。
• 更改基础发行版或镜像变体前，必须说明。