返回

2026/10/28

Node2Shell(CVE-2026-111497):哪些系統面臨風險,現在該怎麼做

Brotli 漏洞 CVE-2026-111497 實際影響哪些系統、各種情境的緊急程度,以及立即修補、重建、重新啟動與緩解的步驟。

更新於 2026 年 10 月 27 日

CVE-2026-111497 俗稱「Node2Shell」或「HTTP2Shell」,是 Brotli 解壓縮器中的記憶體損毀漏洞。Brotli 就是網路上廣泛使用的 br 壓縮格式。此漏洞存在於 Google Brotli 函式庫 1.0.3 至 1.2.0 版 [1]。Node.js 內含此函式庫,Node.js 專案將此問題在 22.x、24.x 與 26.x 版本線的嚴重性評為 High [2]。相同的解碼器也存在於 Python 套件、Linux 系統函式庫、桌面應用程式與開發者工具中,因此實際的曝險範圍遠不止「Node.js 伺服器」。

本文適合需要快速判斷自身是否受影響、以及應優先處理哪些事項的團隊。

重點:只要您有任何系統會解壓縮來自您無法掌控之來源(網際網路上的用戶端、外部網站、Webhook 發送端、上傳的檔案)的 Brotli 資料,就應視為緊急事項。請修補、重建、重新啟動,並在此期間封鎖 br。

漏洞的運作方式

解碼器無法正確處理壓縮串流中格式錯誤的「區塊切換」(block switch)。它將此錯誤視為「需要更多輸入」而非「資料無效」,並持續將位元組附加到一個固定大小的小型內部緩衝區,直到寫入超出其範圍 [2]。能讓您的應用程式解壓縮特製 Brotli 串流的攻擊者,就能破壞處理程序的記憶體。這可能導致:

  • 當機(阻斷服務)。這是最穩定可重現的結果。
  • 處理程序記憶體外洩。回應或日誌可能洩漏機密、權杖或其他使用者資料的片段。
  • 可能的遠端程式碼執行。Node.js 將 RCE 列為可能的影響 [2]。第一個公開的概念驗證(PoC)僅在刻意弱化的建置上達成程式碼執行,但之後研究人員回報,在未經修改的官方 Node.js 24.22.0 建置上也能達成程式碼執行,只是成功率不穩定 [3]。

攻擊不需要身分驗證:攻擊者只需讓位元組送達解碼器即可。這正是 CVSS 4.0 評分為 9.2(Critical)的原因 [1]。因此,對每個系統而言,關鍵問題不是「我們有沒有使用 Brotli?」,而是「不受信任的一方能否讓我們解壓縮 Brotli?」

典型使用情境及其風險

情境 1:接受壓縮請求本文的對外 API(最高優先)

部分 Node.js API 伺服器、BFF、API 閘道與上傳端點會解壓縮以 Content-Encoding: br 傳送的請求本文,也有些是透過中介軟體執行相同處理。風險:網際網路上任何匿名用戶端都能傳送特製的請求本文。影響範圍從反覆讓服務當機(一種低成本的 DoS),到從持有工作階段資料與 API 金鑰的處理程序中洩漏記憶體。緊急程度:緊急。請今天就完成修補,並在完成之前於邊緣端封鎖 br 請求本文。

情境 2:從外部擷取內容的服務(高優先)

Webhook 接收端、網路爬蟲與擷取工具、連結預覽與 RSS 服務、金流或 SaaS 整合,以及會瀏覽網頁的 AI 代理程式,都會發出對外 HTTP 請求。許多 HTTP 用戶端會傳送 Accept-Encoding: br 並自動解壓縮回應。在 Python 中,只要安裝了 Brotli 或 brotlicffi 套件,urllib3 與 requests 就會這麼做,即使您的程式碼從未 import 它。aiohttp 也是如此,而 httpx 在搭配 brotli extra 安裝時同樣會這麼做 [4]。風險:惡意、遭入侵或偽冒的遠端伺服器可以透過回應攻擊您的後端。攻擊者完全不需要進入您的網路:是您主動呼叫對方。緊急程度:高。凡是連線目標不完全可信之處,請優先修補。

情境 3:內嵌執行環境的桌面應用程式、AI 程式設計代理程式與 CLI

Electron 應用程式、以 Bun 或 Node 為基礎的 CLI,以及 AI 開發者工具,都各自帶有一份執行環境。更新系統的 node 套件並無法修正它們。更新磁碟上的應用程式,也無法修正已在執行中的副本:長時間執行的處理程序在重新啟動前,會一直將舊的執行環境保留在記憶體中。風險:這些工具通常持有認證資訊並擷取外部內容,等於是情境 2 再加上一個具特權的處理程序。緊急程度:會擷取不可信內容的工具為高。請更新後確實重新啟動。關於「已更新卻仍在執行舊程式碼」的陷阱,我們在 HTTP2Shell:為何更新二進位檔無法修補執行中的處理程序 一文中有詳細說明。

情境 4:容器映像檔與 CI/CD 產出物

在修正釋出前以 FROM node:22、node:24 或 node:26 建置的映像檔,即使主機已修補,仍含有存在漏洞的執行環境。打包的 Python wheel 與 vendored 相依套件也是如此。風險:在重建映像檔之前,每次部署與每次自動擴展都會讓有漏洞的程式碼重新出現。緊急程度:情境 1 與 2 背後的映像檔為高。請重建,而不只是重新啟動。

情境 5:Linux 系統函式庫、字型與影像處理

各發行版以共用函式庫的形式提供此解碼器,例如 Ubuntu/Debian 上的 libbrotli1。啟用壓縮時 curl 與 libcurl 會使用它,FreeType 處理 WOFF2 網頁字型時會使用它,Pillow 等影像與文件工具也會間接使用它。風險:會轉譯使用者上傳之字型或文件的系統,或以 curl --compressed 擷取外部內容的系統,都可能接收到不可信的 Brotli 資料。從不將外部資料送入這些函式庫的伺服器,實際曝險較低。緊急程度:多數情況為中,但文件轉譯或上傳處理服務為高。Ubuntu 已針對 22.04、24.04、26.04 與 26.10 發布修正後的 brotli 套件 [1]。至於 RHEL、Oracle Linux 及其他發行版,請查閱廠商針對 brotli 套件的安全公告,不要自行假設其狀態。

情境 6:僅處理可信輸入的內部系統(較低優先)

有些服務只解壓縮您自己產生的 Brotli 資料,例如內部快取或自有的建置產出物。這類系統風險較低,但並非為零:已取得立足點的攻擊者可以利用此漏洞進一步擴大入侵。緊急程度:於下一個例行週期修補。

因應措施:處理步驟

步驟 1:找出解碼 Brotli 的位置(今天完成)

  • Node.js:在每台主機、每個容器映像檔與 CI 執行器上檢查 node -v。在程式碼與設定中搜尋 brotliDecompress、createBrotliDecompress,以及會解壓縮 br 的請求本文解析中介軟體。
  • 內嵌執行環境:列出使用中的 Electron 應用程式、Bun/Node CLI 與 AI 代理程式,並記錄各自內嵌的執行環境版本,而不只是應用程式版本。
  • Python:在每個環境與映像檔中執行 pip show Brotli brotlicffi。在鎖定檔與 SBOM 中查找 httpx[brotli] 及間接相依引入的情況。
  • 作業系統套件:執行 dpkg -l | grep brotli 或 rpm -qa | grep brotli,再確認哪些處理程序實際載入了此函式庫。
  • 依上述情境排定優先順序:凡是不可信輸入能觸及者(情境 1、2、3,以及涉及上傳的情境 5)一律優先。

步驟 2:修補受影響的元件

  • Node.js:升級至 22.23.4、24.22.1 或 26.12.1 或更新版本 [2]。
  • Python:Brotli>=1.2.1 或 brotlicffi>=1.2.1.0。重新產生鎖定檔 [4]。
  • 上游 Brotli/vendored C 程式碼:依分支使用 1.0.10、1.1.1 或 1.2.1 [1]。
  • 作業系統套件:套用發行版針對 brotli / libbrotli 的安全性更新。
  • 桌面應用程式與代理程式:更新至廠商明確表示已包含修正後執行環境的版本。若廠商尚未發布任何說明,應將該應用程式視為未經驗證,而非安全。

步驟 3:重建、重新部署並重新啟動

  • 以已修補的基礎映像檔重建容器映像檔並重新部署。重新啟動舊映像檔沒有任何幫助。
  • 重新啟動所有曾載入有漏洞函式庫的長時間執行處理程序:Node 服務、worker、代理程式工作階段,以及任何連結該系統函式庫的程式。對於有狀態的工作與 AI 代理程式,請先排空或移交工作,以免遺失佇列中的事件或核准。

步驟 4:修補期間採取緩解措施

  • 傳入:在反向代理、負載平衡器或 WAF 上,於任何解碼器處理之前拒絕 Content-Encoding 含有 br 的請求本文。
  • 傳出:只從 Accept-Encoding 移除 br 並不足夠,因為惡意伺服器仍可傳送 br。也應拒絕或不解碼帶有 Content-Encoding: br 的回應 [4]。
  • Python 替代方案:若必須延後升級,可解除安裝 Brotli 與 brotlicffi,讓用戶端不再解碼 br。請先測試,因為部分伺服器仍會傳送 br。

步驟 5:驗證並留意遭利用的跡象

  • 從執行中的處理程序或容器內部確認執行環境版本,而不只依賴套件管理工具。
  • 重新掃描映像檔與 SBOM,確認沒有舊副本仍透過間接相依被引入。
  • 檢查近期日誌,查看處理 br 的服務是否出現無法解釋的當機、區段錯誤或重新啟動迴圈。來自單一來源的集中當機,值得視為攻擊嘗試加以調查。
  • 若高曝險服務在修補前曾意外當機,由於無法排除記憶體外洩的可能,請考慮輪替該處理程序所持有的機密。

總結

情況風險措施
公開 API 會解碼 br 請求本文重大立即修補;於邊緣端封鎖 br
後端會擷取外部 URL、Webhook 或網頁高立即修補;拒絕 br 回應
內嵌執行環境的 Electron 應用程式、AI 代理程式或 CLI高更新並重新啟動所有執行中的執行個體
舊的容器映像檔與 CI 產出物高以已修補的基礎映像檔重建並重新部署
用於上傳、字型或 curl --compressed 的系統函式庫中–高套用作業系統更新;重新啟動載入該函式庫的服務
僅限內部可信資料低–中於下一個週期修補

修補套件只完成了一半的工作。唯有當所有執行中的處理程序、映像檔或內嵌執行環境都無法再以舊程式碼解碼不可信的 Brotli 時,曝險才算真正消除。

參考資料