目前位置： 正文

Node.js Brotli 漏洞已遭利用：受影響版本與站長更新重點

2026-11-01 Web Development 0 0

如果網站跑在 Node.js 上，這幾天應優先檢查執行環境的安全更新。新加坡網絡安全局（CSA）於 2026 年 10 月 30 日警告，Brotli 解壓縮漏洞 CVE-2026-111497 已有遭利用的通報；Node.js 已在 10 月 21 日提供修補。

對站長來說，關鍵是應用會不會解壓縮外界提供的 Brotli 資料，以及正式服務是否真的換成修補後的 Node.js。只更新網站套件，或看到 CDN 有開防護，都不足以確認執行環境已經安全。

這個漏洞在什麼情況下會觸發？

Brotli 是壓縮格式。這次問題出在解碼器處理異常壓縮資料時，可能寫出內部緩衝區的範圍。Node.js 官方指出，若攻擊者能提供應用會交給 node:zlib 解壓的 Brotli 資料，便可能造成程序崩潰、記憶體資料外洩，甚至遠端程式碼執行。

因此，安裝 Node.js 本身不代表任何請求都能觸發漏洞。要檢查的是資料流：使用者上傳、請求內容，或伺服器向外部網站取得的壓縮回應，是否會進入受影響的解碼器。網站向訪客傳送 Brotli 壓縮檔案，與應用解壓攻擊者控制的資料，是不同方向的操作。

哪些 Node.js 版本需要更新？

以下列出這次安全修補的版本門檻。同一分支中低於門檻的版本需要更新；部署時可採用該分支目前受支援、已包含修補的較新版本。

Node.js 分支 本次修補版本
22.x 22.23.4
24.x 24.22.1
26.x 26.12.1

Node.js 20 已結束支援，不能等這個分支收到同一批修補。仍使用舊分支的專案，應與維護者安排升級至受支援版本，同時確認框架與原生模組的相容性。

評級也要看來源：Node.js 在 10 月 21 日公告將這項問題列為高風險（high）；CSA 的 10 月 30 日警告則列出 CVSS v3.1 9.8 分，並指出已有遭利用通報。這些通報不表示你的網站已遭入侵，但已足以把更新排到優先處理。

自架網站與容器：檢查正在服務的程序

請維護者確認正式應用使用的 Node.js 版本，包括容器、程序管理工具與背景工作。SSH 登入後看到的系統版本，可能與網站程序實際使用的版本不同。

容器部署應更新基礎映像、重新建置並部署，再核對新容器的執行版本；自架服務則須更新執行環境並重新啟動相應程序。部署後檢查登入、API、檔案處理與背景工作，保留可回復的上一版部署資料。若發現異常程序或不明外連，應保留日誌並請維護者進一步調查。

放在 Vercel，也要確認重新部署

Vercel 在 10 月 29 日的公告說明，自 10 月 28 日美西時間上午 11 時起，新部署使用已修補的 Node.js。既有專案應重新部署；仍設定 Node.js 20.x 的專案，須先改用受支援的 22.x 或 24.x。

Vercel 的 WAF 防護只涵蓋經過其網路的流量，無法涵蓋函數向其他伺服器取得的回應。使用 Vercel 前台、但另有自架 API 或後端的網站，仍須更新那些伺服器。自架 Next.js 也應檢查底層 Node.js，不能只看 Next.js 套件版本。

若交由主機商維護，可直接詢問：「這個站實際使用哪個 Node.js 版本？是否已包含 CVE-2026-111497 修補並重啟服務？」請對方提供執行版本或修補依據，比只確認防火牆已開啟更有用。

資料核對日期：2026 年 11 月 1 日。封面為 AI 生成的漏洞概念插畫，並非攻擊畫面。

參考資料

原文鏈接：https://wntheme.com/nodejs-brotli-cve-2026-111497-security-update/，轉載請註明出處。
0

猜妳喜歡

LiteLLM 1.107.0 供應鏈事件：使用 AI 閘道的網站先核對部署版本
Web Development
網站安全

LiteLLM 在 2026 年 10 月 21 日通報發布管線遭入侵，惡意內容經由 1.107.0 套件與部分官方容器映像散布。
2026-10-22 0 0
2026-10-22
Next.js 10 月緊急安全更新：兩項 RCE 與 Server Actions 阻斷服務
Web Development
網站安全

Next.js 在 2026 年 10 月 14 日發布 16.4.1 與 15.5.28 安全更新，處理兩項嚴重遠端程式碼執行問題及一項高風險阻斷服務問題。
2026-10-15 0 0
2026-10-15
網址中的加號變空白：用URLSearchParams保留C++
Web Development
javascript網址

搜尋框輸入「C++」，結果頁卻顯示「C 」。網址看起來也有兩個加號，為什麼程式讀出來就變成空白？問題常出在把使用者的值直接接進 query string：URLSearchParams解析這類查詢參數時，會把原始加號解讀成空白。 保留真正的加號，做法是把原始值交給URLSearchParams，由它負責編碼。不要先手動拼網址，也不要先encodeURIComponent再append。這兩種處理順序，會讓加號消失或讓百分號被編碼第二次。 同樣是C++，傳入方式決定結果 下面的例子可在瀏覽器Console或支援URLSearchParams的Node.js執行。第一段直接把查詢字串交給建構子，兩個加號被解析為兩個空白；第二段把值當成資料加入，序列化時才把加號變成%2B。 const broken = new URLSearchParams('q=C++'); console.log(JSON.stringify(broken.get('q'))); // "C " const params = new URLSearchParams(); params.append('q', 'C++'); console.log(params.toString()); // q=C%2B%2B console.log(params.get('q')); // C++ 這不是JavaScript把所有加號都改掉，也不是網址任何位置都遵守同一條規則。這裡談的是URLSearchParams採用的application/x-www-form-urlencoded查詢參數解析與序列化。真正的空白序列化為加號，真正的加號則需要百分比編碼，兩者才能分開。 若你已經拿到一段完整query string，建構子會把它當成已編碼的資料解析。如果你手上拿的是使用者輸入、資料庫值或程式算出的文字，就應把它當成原始值交給append或set。先辨認現在拿到的是哪一層，才不會解碼或編碼兩次。 建立網址時，讓URL管理路徑與查詢參數 站內搜尋可以先建立URL，再使用searchParams設定值。這樣遇到加號、空白、&或中文時，不必自己判斷哪些字元會切開下一個參數。下例用示範網址，不會發出網路請求。 const url = new URL('https://example.com/search'); url.searchParams.set('q', 'C++ & template'); url.searchParams.set('page', '1'); console.log(url.search); // ?q=C%2B%2B+%26+template&page=1 const received = new URL(url.href); console.log(received.searchParams.get('q')); // C++ & template 畫面顯示查詢內容時，使用解析後的值，例如input.value或textContent。不要把它直接塞進innerHTML；正確編碼網址，並沒有讓輸入內容變成可安全執行的HTML。網址組裝、HTML顯示與後端搜尋，是不同的處理位置，應各自使用合適的方法。 例子中的page是字串，不代表它已經成為有效頁碼。後端仍要檢查是否為允許範圍的整數，搜尋詞也要按產品需求限制長度。URLSearchParams負責結構與編碼，沒有替你完成資料驗證或存取權限檢查。 不要把encodeURIComponent結果再當原始值加入 常見修法是先把C++變成C%2B%2B，再交給append。這時URLSearchParams收到的原始資料已包含百分號，會把百分號編碼成%25，結果多出一層。接收端解析一次後，得到的是帶有%2B的文字，並不是原本的C++。 const twice = new URLSearchParams(); twice.set('q', encodeURIComponent('C++')); console.log(twice.toString()); // q=C%252B%252B console.log(twice.get('q')); // C%2B%2B encodeURIComponent本身有它的用途，但不要把它和URLSearchParams疊在同一個值上。當舊程式已經明確手動建立某個URL元件時，可以依該元件規則使用編碼；若改成URLSearchParams管理query，就讓它接收原始鍵名與值。把這個交接位置寫清楚，比在結果上不斷replace更容易維護。 同樣地，get已經回傳解析後的值，通常不應再decodeURIComponent一次。例如使用者本來搜尋字面文字「%2B」，解析一次正好保留這三個字元；再解碼就會把它變成加號，改掉原意。不要為了修一個案例，讓另一類搜尋詞出錯。 同名參數要先決定是否允許多個值 append會新增一項，同名鍵可以重複。set則設定該鍵的值，並移除該鍵其他既有項目。若篩選器允許多個分類，重複鍵可能正是你要的結構；單一搜尋詞則通常用set較清楚。讀取時get只取第一項，要取得全部才用getAll。 const...
2026-10-04 59 0
文尼先生 2026-10-04
下載檔名亂碼怎麼查：核Content-Disposition與UTF-8
Web Development · 精品教程
HTTPUTF-8檔案下載

網站上的下載連結寫「模板檢查表」，存到電腦後卻變成一串百分比編碼，或只剩download.csv。先別重新壓縮整包檔案：瀏覽器採用的檔名，可能來自下載回應的Content-Disposition，與頁面上的連結文字不同。 這篇處理下載檔名與UTF-8編碼。檔案能否下載、會員是否有權限，則屬於另外的功能；檔名顯示正常，也不能證明下載內容正確。 先分清檔名與檔案內容 下載後，先看錯的是「名稱」還是「打開後的文字」。CSV內中文字亂碼，可能要查檔案實際位元組與開啟軟體；檔案內容正常、名稱卻奇怪，則先查回應標頭。不要把CSV內容加了UTF-8設定，就認定檔名一定跟著修好。 另外記下來源網址與瀏覽器。下載可能經過重新導向，真正送出檔案的是最後一個回應；查看第一個入口的標頭，未必看得到檔名設定。頁面上的下載按鈕文字，也不等於伺服器建議的名稱。 在最後一個回應找Content-Disposition 開啟瀏覽器開發者工具的Network，保留請求記錄，再按下載。找到真正回傳檔案的請求，讀Response Headers。例如： Content-Type: text/csv; charset=utf-8 Content-Disposition: attachment; filename="template-check.csv" attachment表示以附件處理，filename提供建議名稱。這份例子只提供ASCII名稱，所以中文標題不會自動出現在下載檔名。實際儲存行為仍由瀏覽器與檔案系統處理，不要把它當成可以指定訪客電腦完整路徑的指令。 若沒有這個標頭，瀏覽器可能依URL或其他條件取得名稱。先記錄目前回應，不必立刻到所有頁面加相同屬性；請維護下載程式的人核對真正送檔的入口。 中文名稱放在filename*，保留簡單備用檔名 需要非ASCII名稱時，可由回應提供filename*，使用指定字元編碼及百分比編碼。下面同時保留英文備用名稱，中文部分代表「模板檢查.csv」： Content-Disposition: attachment; filename="template-check.csv"; filename*=UTF-8''%E6%A8%A1%E6%9D%BF%E6%AA%A2%E6%9F%A5.csv UTF-8''後方是UTF-8檔名的編碼，不是把中文字隨便塞進標頭。支援這個參數的處理端會優先使用filename*；保留ASCII的filename，可讓不理解擴充寫法的處理端還有合理名稱。 注意兩個單引號的位置，也不要同時輸出兩個相同的filename*。如果使用的框架已有下載回應方法，先查它如何接收Unicode檔名與產生標頭，不要在既有設定後再手動追加一份，造成重複參數。 百分比編碼只做一次 常見失誤是先把檔名編成%E6...，再交給會自行編碼的程式。第二次把百分比符號變成%25，瀏覽器解碼一次後，仍得到一串%E6...，而非原本的中文。 可先用JavaScript查看一次編碼的結果，但實際標頭仍由下載伺服器產生： encodeURIComponent('模板檢查.csv'); // %E6%A8%A1%E6%9D%BF%E6%AA%A2%E6%9F%A5.csv 這個例子不包含撇號等需要額外處理的字元，不能把它當成完整通用的Content-Disposition產生器。正式程式應使用框架或函式庫提供的標頭編碼方法，先確認輸入要的是原始Unicode名稱，還是已編碼字串。 不要把擴充參數的寫法直接搬進普通filename。百分比編碼在filename中的處理並非所有瀏覽器一致，可能一個瀏覽器看起來正常，另一個保留原字串。可預期的ASCII備用名稱，比把同一串編碼塞進兩個欄位更容易維護。 用同一份內容，確認改的是哪一層 準備一份不含客戶資料的小檔案，做三個測試回應：只有ASCII備用名稱、filename*編碼一次、filename*重複編碼。檔案內容保持完全相同，再比較瀏覽器建議名稱與下載後的內容。 本文CSV案例的三個入口送出相同位元組；Chromium取得的名稱依序是template-check.csv、模板檢查.csv與仍帶百分比文字的名稱。這能分清標頭造成的差異，不代表所有瀏覽器都會給出相同結果。 保存下載檔後，再以同一種方式查看內容或計算雜湊。若三份內容相同，就別把名稱修正說成資料修復。反過來，如果內容也不同，回頭查是否拿到了登入頁、錯誤訊息或另一個檔案，不能只靠副檔名判斷。 別把路徑與私人資料當成檔名 檔名只需要識別文件。避免使用完整伺服器路徑、私人Email或客戶識別碼，也不要相信使用者傳入的檔名可以直接寫進標頭。保留合理副檔名，清理控制字元與路徑分隔符；下載目標仍由功能自己的資料與授權流程決定。 瀏覽器可能為配合檔案系統調整不允許的字元。同名檔案已存在時，儲存端也可能加序號。看到「模板檢查(1).csv」，先確認是否是本機已有同名檔，而不是立刻判定伺服器又多編碼一次。 修正前保存原下載回應設定和標頭，只改一個測試入口。用自己的正式支援瀏覽器重試中文、空白與ASCII名稱，確認內容、格式、檔名都正確，再擴大到其他下載功能。 如果檔名正常卻無法下載，請另查回應狀態與下載行為；如果內容開啟後亂碼，則把實際檔案交給負責內容編碼的人。這樣維護者知道應該修標頭、檔案位元組，還是下載功能本身。 參考資料 MDN：Content-Disposition RFC 6266：HTTP附件檔名與擴充參數 RFC 8187：HTTP標頭參數的字元編碼 MDN：encodeURIComponent
2026-10-04 82 0
文尼先生 2026-10-04
網站第三方腳本載入失敗：讓核心內容先能用
Web Development · 精品教程
javascript漸進增強網站維護

第三方聊天、推薦或統計腳本載入失敗，不應讓整篇文章只剩轉圈圈。訪客來讀內容，至少要能看到正文、用普通連結前往下一頁，並知道附加功能現在能不能用。 先分清哪些功能是核心，哪些只是加強。網站需要登入或付款才能完成的動作，不能用假成功提示替代；但文章閱讀、聯絡方法與基本導覽，通常可以先保留在原始HTML裡。 先看停用附加腳本後，還剩什麼 挑一個自有測試頁，記下訪客最常做的動作，例如閱讀教學、打開分類或找到聯絡方法。只阻擋準備檢查的附加腳本，再重新整理。若正文消失，或普通連結也必須等那支腳本建立，核心入口就過度依賴它。 本文的文章頁案例，正文與連結先在HTML裡，附加導覽再透過一個獨立腳本啟用。阻擋該腳本後，文章仍在、原生details仍能展開、普通連結仍能移到說明；側邊只改成「暫時無法使用」與替代入口。 附加服務失敗只影響自己的區塊，閱讀入口仍然保留。 這是可操作的文章頁範例，不是第三方產品後台。正式網站要按自己的工具和主題檢查，不能因範例保留了連結，就推成所有付款、搜尋或會員功能都有替代路徑。 把基本內容先寫在HTML 連結要有真正的href，不要只留一個onclick。按鈕用於展開或觸發動作；前往另一頁的入口則使用連結。即使附加程式沒有執行，訪客仍能辨識下一步。 <article> <h2>網站導覽說明</h2> <p>先整理主要分類與聯絡入口。</p> <a href="/guides/navigation/">閱讀完整說明</a> </article> <aside> <p id="extra-status" role="status"> 附加服務載入中，可先使用文章連結。 </p> <div id="extra-widget"></div> </aside> 範例網址要換成自己存在的頁面。不要先用CSS把所有正文隱藏，等第三方成功才移除class；這樣即使HTML已經有內容，腳本失敗仍會把文章藏住。先讓正文可讀，再逐步增加附加互動。 載入失敗與執行失敗，要各有出口 外部script資源載不回來，可以由error事件處理；載回來後初始化函式拋錯，則需要對初始化另做處理。兩者不是同一件事。script的load事件發生，不能單憑它就顯示整個服務已正常運作。 const status = document.querySelector('#extra-status'); const script = document.createElement('script'); const showFallback = () => { status.textContent = '附加服務暫時無法使用，請用文章連結。'; }; script.src = '/assets/optional-widget.js'; script.onload = () => { try { if (!window.OptionalWidget) throw new Error('missing widget'); window.OptionalWidget.mount(document.querySelector('#extra-widget')); status.textContent = '附加服務已就緒。'; } catch (error) { showFallback(); } }; script.onerror = showFallback; document.head.append(script); 這段用示例物件說明邊界，並非所有工具都叫OptionalWidget。使用真實服務時，依它的正式初始化方法和錯誤回傳調整。若初始化本身是非同步，還要處理它的Promise拒絕；同步try/catch不會自動接住稍後才發生的非同步錯誤。 回饋區寫的是附加服務狀態，不要擋住整篇文章，也不要讓每次重試都彈出全頁視窗。失敗原因留在維護紀錄；訪客需要知道的是目前可用入口與下一步，不必看到一串程式堆疊。 defer與async不是失敗備援 調整script載入方式可以影響解析與執行時機，但不會自動建立替代內容。即使加了defer，腳本404、被阻擋或初始化失敗，原本依賴它的功能仍可能不能用。...
2026-10-04 49 0
文尼先生 2026-10-04
網站重新導向串太多：追出每一步網址與狀態碼
Web Development · 精品教程
HTTP網站維護網站轉址

舊文章網址最後能開啟，不代表中間沒有繞路。瀏覽器可能先從舊路徑轉到過渡頁，再轉到新文章；地址列只留下最後一個網址，兩次跳轉就被藏起來了。 排查重新導向串時，先保留每一步的 URL、狀態碼與 Location，確認哪一步還有必要。這篇用兩段 HTTP 回應示範怎麼追，不處理 canonical 的選擇，也不要求一開始修改正式主機規則。 先看第一個回應，不自動追到底 在開發者工具的 Network 勾選保留記錄，再輸入舊網址。找到第一個文件請求，檢視 Status 與 Response Headers 的 Location。接著找 Location 指向的下一個請求，重複到最後頁面。 例如舊路徑 /old-guide 回301，Location 是 /middle-guide；middle-guide 再回302，Location 是 /final-guide；final-guide 才回200。訪客要讀最後的文章，瀏覽器先做了兩次轉向。 /old-guide → 301 Location: /middle-guide /middle-guide → 302 Location: /final-guide /final-guide → 200 Location 可以是相對地址，不能只把字串貼在另一個網域上猜。按上一個回應的 URL 解析，再核對實際下一個請求。遇到跨網域、http轉https或尾斜線變更，也各自算一步，別把它們合併成「瀏覽器自己修好了」。 用 curl 儲存每一步 在 Windows 終端機可明確使用 curl.exe，避免叫到不同工具的同名指令。先用不帶 -L 的請求檢視第一個回應；-o NUL 不輸出正文，-D - 把標頭寫到畫面： curl.exe -sS -D - -o NUL "https://example.com/old-guide" Linux 或 macOS 把 NUL 換成 /dev/null。這裡仍是 GET，不是 HEAD；有些網站對 HEAD 的處理不同，拿 HEAD 的結果代替訪客實際GET可能漏掉差異。對需要登入或特殊 Cookie...
2026-10-04 57 0
文尼先生 2026-10-04
顯示驗證碼
沒有帳號？註冊  忘記密碼？