Node.js 一次修了 10 個漏洞，升級的關鍵不是版本號，是重新部署

發生了什麼

10 月 21 日早上我們才寫完 PHP 核心雙 RCE 那篇，傍晚 6 點 38 分，Node.js 也一次發了三個版本。我們自己的站跑的是 Next.js，所以這次不是替別人拆，是先翻自己的設定：正式站到底跑哪一版 Node？誰決定的？要怎麼確認換上修補版了？翻到一半才發現，package.json 裡連 engines 都沒寫。這篇就從那張「我們自己也答不出來」的表開始，拆官方公告講了什麼、哪些伺服器真的在射程內，以及一套中小團隊今天就能照做的修補流程。

先講清楚第一手文件的性質。Node.js 的安全公告是專案自己發的修補通知，格式固定：漏洞標題、嚴重度、影響哪幾條版本線、誰回報、誰修。它不會附觸發細節，也不會給 PoC；這是刻意的，好讓大家先升級。這篇能補上的部分，來自發布說明裡的 commit 清單、Vercel 的公告，以及資安媒體的整理，那些我會另外標出來。

修補版本：v22.23.4、v24.22.1、v26.12.1
最高嚴重度：三條線都是 HIGH

HIGH
CVE-2026-111497  Brotli 解碼器越界寫入，可遠端執行程式碼（22／24／26）
CVE-2026-105482  dns.resolve 遇到含 NUL 字元的名稱會截斷（22／24／26）
CVE-2026-105483  IP 以全形數字書寫時，TLS 憑證主機名稱驗證可被繞過（24／26）
CVE-2026-106069  主機名稱可寬鬆解析成 IP 時，TLS 憑證主機名稱驗證可被繞過（22／24／26）
MEDIUM
CVE-2026-105481  keep-alive 連線可能處理到請求送出前就寫入的回應
CVE-2026-106072  非標準 IPv4 主機名稱讓 DNS SAN 憑證可通過 IP 端點驗證
CVE-2026-106074  crypto.randomUUID()／randomInt() 的亂數快取被存進啟動快照與 SEA
LOW
CVE-2026-106070  ZipFile 驗證失敗後回傳攻擊者控制的前綴位元組（26）
CVE-2026-106071  Permission Model 萬用字元比對過度授權（26）
CVE-2026-106073  Permission Model 可經 fs.realpathSync 繞過

相依套件：c-ares、ca-cert（eMudhra 中繼憑證外洩）、OpenSSL（22／24）、SQLite（22）、Undici
停止支援的版本：每次安全更新都一定受影響

把能查到的時間排開。注意第一列：Node 這次修 Brotli 用的，是上游八個月前就提交的一個修正。

1. 2026-02-27
   Google Brotli 上游提交 commit 0ed4268a，說明是「更早偵測並回報無效的資料流」
   GitHub 上的 commit 紀錄；Node 三份發布說明都寫 deps: brotli: cherry-pick 0ed4268a4401 對應 CVE-2026-111497
2. 2026-04-30
   Node.js 20 停止支援（End-of-Life）
   Node.js Release 工作小組 schedule.json；官方公告寫停止支援的版本在每次安全更新都受影響
3. 2026-10-17～10-18
   研究者通報 eMudhra 八把中繼憑證私鑰外洩，eMudhra 於 10-18 以 caCompromise 撤銷；Chrome 與 Firefox 當晚陸續封鎖
   The Hacker News、Scott Helme 等報導；本站未取得 eMudhra 的原始公告
4. 2026-10-20
   Node.js 24 從 Active LTS 進入維護期 LTS（Maintenance）
   schedule.json；維護期仍會收到安全修補
5. 2026-10-21 10:38 UTC（台灣 18:38）
   Node.js 22.23.4、24.22.1、26.12.1 在 GitHub 同時發布；同日官方公告列出 10 個 CVE 與相依套件更新
   nodejs/node GitHub Releases 時間戳；nodejs.org 安全公告與三份發布說明
6. 2026-10-21
   Vercel 發布公告：當天已在 WAF 加規則擋流入的攻擊流量，並陸續替託管執行環境換上修補版；Node 20 專案必須自己改版本重新部署
   Vercel 公告（Vercel 自己的說法）
7. 2026-10-22 09:41（台灣）
   本站在 package.json 加上 engines：node 24.x
   本站 git 紀錄
8. 未公開
   Brotli 漏洞的觸發細節、經由哪些 API 路徑可以碰到、是否已有人利用
   官方公告沒有觸發細節，也沒有回報野外利用；SecurityOnline 整理時寫目前沒有已確認的公開 PoC

修補從發布到我們自己動手，隔了大約 15 個小時；而且動手的那一步，只是把主版本鎖住。後面會講為什麼這還不夠。

怎麼發現

官方公告沒有寫 CVE-2026-111497 是怎麼被發現的，只寫了回報者是 Node.js 核心維護者 mcollina、修補者是 aduh95。修補內容是 cherry-pick 上游 Brotli 的一個 commit，加上一個把「區塊切換格式錯誤」這種錯誤碼開放給 JavaScript 層的小改動。兩個 TLS 主機名稱繞過與 dns.resolve 的問題，回報者是外部研究者。

eMudhra 那一條則完全是另一條線：10 月 17 日（週六）有研究者通報 eMudhra 的八把中繼憑證私鑰外洩，瀏覽器在一兩天內封鎖。Node.js 預設的 TLS 不檢查憑證撤銷清單，所以 eMudhra 撤銷了憑證，對 Node 程式來說等於沒有；只有更新 Node 內建的根憑證與封鎖清單，才擋得住拿那幾把私鑰簽出來的假憑證。這次的發布說明裡就有「tls: reject chains containing blocked public keys」與「crypto: update root certificates to NSS 3.131.1」兩項。

攻擊者怎麼做到

到這裡，其實已經足夠理解整起事件。如果你關心的是該怎麼避免，可以直接往「如何避免」繼續閱讀。如果你想知道公開資料能還原到哪一步，下面開始進入技術拆解。

白話結論：Node 不會自己去解壓縮 Brotli，所以光是「跑 Node」不等於中招。要在射程內，你的程式或某個套件必須會解開一段攻擊者能控制的 Brotli 資料；而現代的 fetch 遇到伺服器回 Content-Encoding: br，會自動替你解壓縮。

為什麼「替使用者抓網址」的服務最危險？

因為 Brotli 資料有兩個方向可以進來，而 WAF 只看得到其中一個。

• 流入：攻擊者把 Brotli 壓縮過的內容放在請求裡送給你，而你的伺服器或某個中介套件會解開它。這個方向走得過 WAF，Vercel 說它當天就在 WAF 加了規則。
• 流出再流入：你的伺服器主動去 fetch 一個網址，對方回一段 Brotli 壓縮的回應，fetch 自動解壓縮。這個方向是你自己發起的連線，WAF 看不到；Vercel 的原話是「只有執行環境的修補涵蓋抓回來的回應」。

所以會替使用者抓任意網址的功能，像是連結預覽、webhook 測試按鈕、圖片代理、RSS 爬蟲、AI 代理的網頁抓取工具，都應該排在升級清單的最前面。Vercel 另外點名：自架的 Next.js 圖片最佳化不會擋 Brotli 回應。

五格裡只有前兩格有官方或廠商的文字，後三格是取得執行權之後的一般形狀，不是本次事件的紀錄。

這次外洩了什麼

這是一次修補更新，不是外洩事件，目前沒有任何公開的受害案例。下表列的是「如果被利用，哪些憑證會在射程內」，全部是推論或空白。

如果你的服務在射程內又來不及升級，第三欄那幾種東西就是你要預先準備輪替的清單。

證據等級

能證明的三件事是：修了什麼、哪幾版修了（含 eMudhra 的處理）、Node 20 不會修。只能推的是射程與可利用性。沒人講的有三件。

他們怎麼處理

照官方公告排一次。Node.js 專案先在公告頁預告發布日期，10 月 21 日同時發布三條版本線，公告逐條列出 CVE、嚴重度、影響版本、回報者與修補者，並附三份發布說明的連結；沒有觸發細節，也沒有替停止支援的 Node 20 出修補。同一批更新順手處理了 eMudhra 的憑證問題，以及 c-ares、OpenSSL、SQLite、Undici 這些內附套件的已知漏洞。

平台端的處理以 Vercel 最完整：當天在 WAF 加規則擋流入的攻擊流量，逐步替託管的 22.x、24.x 執行環境換上修補版，使用者不用改設定；Node 20 專案則必須自己改版本重新部署。公告也明講 WAF 擋不到函式主動抓回來的回應，以及自架 Next.js、自建容器、CI runner、本機開發環境都要自己升級。

哪裡做對，哪裡做錯

Node.js 專案做對的地方是節奏：三條線同一分鐘發布，公告格式固定，每一條都寫清楚影響哪幾條線，維護期的 24 也照樣修。eMudhra 的處理很快，從瀏覽器封鎖到 Node 內建根憑證更新只隔了三天。該改的地方是那八個月：上游 Brotli 二月就有修正，Node 十月才帶進來；就算當時沒人知道它是安全問題，這也說明「內附的第三方函式庫跟上游差多少」是一個需要被追蹤的數字。

使用者這一端，最常見的錯是把「設定了版本」當成「已經修好」。engines 寫 24.x、Dockerfile 寫 FROM node:24、PaaS 選 Node 24，三者都只保證主版本；真正換上修補版的是那一次重建。我們自己就是這樣：鎖了主版本，修補版還沒核對。

如何避免

這一節寫給有好幾個 Node 服務、但沒有專職維運的團隊。

當天就能做的，是把清單做出來。每一台主機、每一個容器映像、每一條 CI、每一台開發機，各跑一次 node -v，列成一張表：服務名稱、Node 版本、怎麼裝的（官方二進位、發行版套件、Docker 基底映像、PaaS 託管）、會不會替使用者抓外部網址。版本低於 22.23.4／24.22.1／26.12.1 的標黃，20.x 以下的標紅。

升級順序照風險排，不是照方便排：

• 第一批：會替使用者抓外部網址的服務（連結預覽、webhook、圖片代理、爬蟲、AI 代理的抓取工具），以及還在 Node 20 以下的對外服務。
• 第二批：其他對外服務、以 IP 呼叫內部 TLS 服務的元件、用啟動快照或 SEA 打包的程式。
• 第三批：CI runner、內部工具、開發機。

每一批的動作都是三拍：改版本，重建（Docker 用修補後的基底映像、PaaS 觸發重新部署、SEA 重新打包），再到執行環境裡印出 process.version 確認。第三拍最常被省略，也是我們自己還沒做完的那一拍。

一個月內，把「鎖主版本」變成「鎖修補版本」。Dockerfile 寫到 node:24.22.1 或固定 digest；.nvmrc 或 .node-version 寫完整版本號；PaaS 若支援指定完整版本就指定。好處是下一次安全更新出來時，升級是一個看得到的 commit，而不是一次碰運氣的重新部署。

這一季要建的是流程：訂閱 nodejs-sec 郵件列表；每次安全更新出來，48 小時內完成第一批；每季盤點一次停止支援的版本，Node 22 的停止支援日是 2027 年 4 月 30 日，現在就該排進明年第一季。

這篇提到的項目要花多少錢

Node.js 本身免費，這次的成本幾乎都是人力與重建。下表除了官方與廠商公開的價格，其餘都是本站估算。

第二、三列加起來大約 NT$7,500，就是一個小團隊把這次更新做完整的成本；把版本鎖到修補號之後，下一次會更便宜。

你可以學到什麼

站在攻擊者那一側看，執行環境的漏洞是最好的投資：不用研究你的程式，只要你的版本號落後。修補一公開，差異就是一份說明書；而大部分團隊的版本號是「上次部署那天平台剛好給的那一版」，沒有人知道是哪一版。對他來說，最好的目標是一個會替使用者抓網址、又跑在舊版 Node 上的服務，因為那條路連 WAF 都看不到。

跟我們的防暴筆記對照

最直接的對照是同一天的〈PHP 核心兩個 RCE 在修補前外洩〉。兩個執行環境同一天出緊急修補，共同的問題都不是漏洞本身，而是「停止支援的版本不會修」：PHP 那邊是六成對外主機跑 8.1 以下，Node 這邊是 20 已經停止支援半年。兩篇的第一步一樣：先知道自己每一台跑哪一版。

第二個對照是我們自己的 INC-2026-0915（「關機前套用更新」這支程式，跑了 17,613 分鐘）。那一次是網頁程式被打穿之後，攻擊者在主機上潛伏了 356 天，靠的是沒人看網頁程序底下多了什麼。如果 Brotli 這個洞被利用，取得的就是 Node 程序的權限，之後的形狀會很像：異常子程序、陌生排程、CPU 長時間滿載。修補是第一道，主機層的偵測是第二道。

第三個對照是早上剛寫的〈替你保管所有 AI 金鑰的那一層，被換成了竊密程式〉。那篇的教訓是「固定版本與雜湊，不追浮動標籤」；這篇是同一句話的另一面：固定版本不只是為了不被換成壞的，也是為了確定自己已經換成好的。

回到那張表

這篇最有用的東西，不是 10 個 CVE 的清單，是那張「每個環境跑哪一版 Node」的表。有了它，下一次安全更新出來，你知道要升哪幾台、先升哪一台、升完怎麼確認；沒有它，每一次都是從「我們有用 Node 嗎」開始問起。

我們自己的表還沒填完：正式站鎖了 24.x、修補版待核對，本機開發機還停在已經停止支援的 23。寫這篇的目的之一，就是逼自己把它填完。