Node.js 公布並修補 12 個漏洞，影響 22.x、24.x、26.x；其中兩個高風險漏洞分別涉及 WebCrypto 的整數溢位與 TLS 主機名稱正規化不一致，官方已釋出對應修補版本。
開放原始碼 JavaScript 執行環境 Node.js 近期發布安全性更新公告，揭露並修補 12 個漏洞，其中包含 2 個高風險、6 個中風險與 4 個低風險漏洞，且 CVSS 評分尚未公布。[7] 受影響版本為 Node.js 22、Node.js 24 與 Node.js 26；開發團隊已釋出修補版本 Node.js 22.23.0、Node.js 24.17.0、Node.js 26.3.1。[7]
這次更新不只處理安全問題，也同步納入多個核心元件版本更新，包括 llhttp 9.4.2、nghttp2 1.69.0、OpenSSL 3.5.7，以及 Node.js HTTP/1.1 用戶端程式庫 undici 8.5.0、7.28.0、6.27.0。[原始資料摘要] 這代表此次公告的修補範圍，不是單一模組的局部修正，而是涵蓋網路通訊、加密與 HTTP 解析等關鍵路徑的整體更新。[原始資料摘要]
第一個高風險漏洞是 CVE-2026-48933，問題出在 Node.js 的 WebCrypto 實作。[原始資料摘要] 根據原始情資，AES 加解密實作過程發生整數溢位錯誤，進而導致緩衝區溢位；當 subtle.encrypt() 的輸入容量為 2 GiB 的倍數時，可能導致處理程序停擺。[原始資料摘要] 這類錯誤的危險性在於，它發生在加密 API 的資料處理邊界，若應用程式將大容量資料直接送入 WebCrypto，風險就會由單一請求放大為服務中斷事件。[原始資料摘要]
第二個高風險漏洞是 CVE-2026-48618，問題出在 Node.js 的 TLS 主機名稱處理。[原始資料摘要] 情資指出，當 Node.js 處理 Unicode 間隔符號（·）時，解析器與驗證器對主機名稱的正規化處理不一致，可能使 TLS 萬用字元對多層子網域的驗證遭到繞過，進而造成機密性受損或突破預期安全邊界。[原始資料摘要] 從技術角度看，這是「字串正規化差異」引發的驗證落差，常見於憑證比對、主機名稱匹配與國際化網域處理流程，一旦前後處理邏輯不一致，就可能讓本應被拒絕的憑證通過驗證。[原始資料摘要]
值得注意的是，本次公告同時更新 llhttp、nghttp2、OpenSSL 與 undici，顯示 Node.js 的攻擊面並不只侷限在應用層 API，而是橫跨 HTTP 解析、HTTP/2、TLS 與請求客戶端等多個基礎能力。[原始資料摘要] 對資安團隊而言，這類更新通常意味著應重新檢視依賴鏈，因為上層應用雖未變更程式碼，底層行為卻可能已被修補或調整。[原始資料摘要]
依據公告，受影響的是 Node.js 22、24、26 系列，且官方已明確提供對應修補版本。[7] 這表示使用這些版本的開發、測試與正式環境，都需要盡快確認是否已完成升級。[7]
就風險型態來看，CVE-2026-48933 主要帶來可用性風險，可能造成程序停擺；CVE-2026-48618 則偏向機密性與驗證邊界風險，可能讓 TLS 驗證產生誤判。[原始資料摘要] 兩者雖然技術成因不同，但都發生在高信任元件中，代表一旦被觸發，影響的不只是單一服務，而可能擴散到 API 介面、內部服務互信機制與憑證驗證流程。[原始資料摘要]
由於這次修補也更新了 OpenSSL 與 HTTP 相關元件，實務上需要特別關注採用 Node.js 作為後端執行環境、API Gateway、內部工具、任務處理器或具 TLS 連線需求的服務。[原始資料摘要] 若這些服務依賴大量加密運算、長連線、HTTP/2 或第三方模組，更新前後的穩定性與驗證行為都應列入測試範圍。[原始資料摘要]
首先應立即升級至 Node.js 22.23.0、24.17.0 或 26.3.1，這是官方已提供的修補版本。[7] 若生產環境使用其他分支或自建映像，也應同步確認基底映像是否已重新建置，避免容器仍停留在舊版元件。[原始資料摘要]
其次，應優先盤點是否有應用程式直接呼叫 subtle.encrypt()，或在 TLS 驗證流程中依賴主機名稱比對、萬用字元憑證與國際化字元處理。[原始資料摘要] 這些場景與本次兩個高風險漏洞直接相關，屬於高優先級檢查項目。[原始資料摘要]
第三，更新完成後應觀察錯誤日誌、TLS 握手失敗紀錄與異常程序終止事件，確認是否存在相容性問題或被漏洞觸發的歷史跡象。[原始資料摘要] 若服務中有大量加密或代理相關操作，建議將驗證重點放在 API 回應異常、連線重試次數與憑證比對結果。[原始資料摘要]
第四，對於無法立即升級的環境，應採取暫時性風險控管，例如限制可觸發大容量加密運算的輸入來源，並縮小 TLS 憑證與主機名稱的使用範圍。[原始資料摘要] 這不是長期解法，但可在維運窗口開啟前降低暴露面。[原始資料摘要]
subtle.encrypt()、TLS 主機名稱驗證與萬用字元憑證流程進行功能測試。[原始資料摘要]