Node.js 修補 11 個漏洞：production、CI 同 Docker 點排升級次序
22.x、24.x、26.x 都有修補版，唔使盲目轉 major
Node.js 喺 7 月 29 日推出新一輪安全更新。iThome 報道整理，今次合共修補 11 個漏洞，包括 3 個高風險、5 個中風險同 3 個低風險問題，涉及仍受支援嘅 22.x、24.x 同 26.x。數字望落幾嚇人，不過各漏洞都有觸發條件，唔代表每個 Node.js 網站已經可以俾人直接攻入；部署團隊要睇清楚服務實際用咩功能。
三個高風險漏洞，HTTP/2 佔咗兩個
第一個 HTTP/2 漏洞 CVE-2026-56846 只影響 22.x 同 24.x。惡意連線可以令部分 header 佔用嘅 RAM 逃過 maxSessionMemory 計算，持續食盡程序記憶體，最後拖冧服務。另一個 CVE-2026-56848 影響三條分支，問題出喺 HTTP/2 處理期間重入呼叫，令程式存取已經釋放咗嘅 heap 記憶。呢類 memory safety 錯誤可以令程序失穩；官方公告冇話漏洞可做到遙距執行程式碼，唔應自行誇大成接管 server。
風險最高嘅場景，係 Node.js 程序直接收發不可信 HTTP/2 流量，例如自己開 HTTP/2 server，或者連接外部可控制嘅 HTTP/2 endpoint。如果前面由 CDN、load balancer 或 Nginx 接收 HTTP/2，再用 HTTP/1.1 駁入 Node.js，實際曝露面會細好多，但仍要確認內部服務同 outbound client 有冇用 HTTP/2，唔好見到前面有 proxy 就當完成排查。
--permission 用家要重新檢查個 sandbox
第三個高風險漏洞 CVE-2026-58043 影響三條分支，同 Node.js Permission Model 嘅路徑比對有關。服務開住 --permission，又畀某段程式存取指定路徑時，攻擊者可以利用路徑前綴邊界處理錯誤，讀寫 allowlist 以外嘅檔案。佢要先有程式執行能力同獲准路徑，普通公開 API 請求未必直接觸發；不過 Permission Model 本身就係用嚟困住不可信程式或受感染套件，越界會拆走原先嗰層保護。
其餘漏洞都唔好睇過就算。今次包括 HTTPS Agent 重用連線時混淆 mTLS 身份、TLS session reuse 漏做 hostname 核對、特製 DNS 回覆或偽造 TypedArray 令程序終止，仲有特定 Node.js forwarding proxy 可能出現 request smuggling。用緊 mTLS、多租戶代理、dns.resolveAny()、同步 zlib API 或內置 SQLite 嘅團隊，要將相關測試放入升級驗證清單。
留喺原有 major，直接升安全修補版
22.x 升去 22.23.2，24.x 升去 24.18.1，26.x 升去 26.5.1。 Production 團隊唔使為今次漏洞由 22.x 硬跳去 24.x 或 26.x；先留喺現有 major 套修補，回歸測試範圍會易控制。按 Node.js 官方生命週期，22.x 係 Maintenance LTS、24.x 係 Active LTS，26.x 暫時仍係 Current，要到 10 月先進入 LTS，所以新 production 部署唔應純粹因版本號較新就轉用 26.x。
先喺每個 production instance 執行 node --version，再用 node -p "process.version + ' ' + process.execPath" 確認真正啟動服務嗰份 binary。跟住查 PM2、systemd、serverless runtime 同部署平台設定，因為登入 shell 見到嘅 Node.js 版本，未必同長期運行緊嗰個程序一致。仲用緊已停止支援嘅 20.x、18.x 或其他舊分支，就冇今次公開修補版，要另外安排轉上受支援 LTS。
CI 同 Docker 最易出現「改咗但未生效」
CI 要查 version matrix、setup-node 設定、自建 runner image 同 build log 入面嘅 node --version。如果測試只寫 22 或 24 呢類浮動版本，重新跑 pipeline 前要確認 runner 真係拉到新 patch；如果釘死完整版本，就要直接改成上述修補版。build 階段同 production runtime 都要查，否則可能用新版編譯，最後仍放入舊版 container 執行。
Docker 部署可以先用 docker exec <container> node --version 查現役 container，再核對 Dockerfile 嘅 FROM node:...。就算寫住 node:24，舊 image layer 都唔會自動更新；官方亦提醒 security release 推出後，各架構同 Alpine variant 可能要等數小時先齊。確認相應 tag 已發布後，用 docker build --pull 重建、跑測試再逐批換 container。釘死 digest 嘅團隊亦要更新 digest，單靠重新部署舊 image 解決唔到今次漏洞。
參考來源
- iThome — Node.js揭露與修補11個漏洞，當中涵蓋3個高風險漏洞 — original report
- Node.js：Wednesday, July 29, 2026 Security Releases — 官方安全公告，列明各漏洞觸發方式、受影響分支同修補版本
- Node.js 22.23.2 release notes — 核實 22.x LTS 安全修補內容
- Node.js 24.18.1 release notes — 核實 24.x LTS 安全修補內容
- Node.js 26.5.1 release notes — 核實 26.x Current 安全修補內容
- Node.js Release Working Group — 核對 22.x、24.x、26.x 嘅支援階段同生命週期
- Node.js Docker Official Image — 官方 image tag、LTS 使用建議同 security image 發布安排
- Docker build best practices — 核實用 --pull 取得更新 base image 同重新 build 嘅做法
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
