--- title: "NGINX 高風險漏洞成因與修復指南" description: "整理 2026 年 10 月 NGINX 五項漏洞的觸發條件、分支修復版本、發行版回補、臨時措施與線上驗收。" language: "zh-Hant" url: "https://keendigit.com/zh-hant/insights/nginx-remediation-guide" author: "KeenDigit" published: "2026-10-14" updated: "2026-10-27" --- # NGINX 高風險漏洞成因與修復指南 整理 2026 年 10 月 NGINX 五項漏洞的觸發條件、分支修復版本、發行版回補、臨時措施與線上驗收。 歷史文章日期：2026-10-14（本批漏洞公開及修復日期）。資料核驗與補充截至：2026-10-27。 本文按事件日期歸檔；下文包含 10 月 14 日之後發布的版本與發行版更新資訊。 適用對象：NGINX Open Source / NGINX Plus 的網站與反向代理維運人員、安全回應人員、發行版維護者，以及自編譯 NGINX 和維護第三方模組的工程師。 本文聚焦於 2026 年 10 月 14 日公開並集中修復的五項 NGINX 核心漏洞，同時回溯 2026 年 5—9 月具有代表性的記憶體安全與請求完整性漏洞。內容涵蓋觸發條件、程式碼層成因、影響範圍、正式修復流程、短期緩解措施、官方修補程式實作、舊分支回補及上線驗收。內文採用 [S1](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-1) 等編號引用，全部參考連結集中列於文末附錄。範例配置僅用於說明部署與稽核思路，應依實際版本、配置繼承、相依性及業務容量驗證後再實施。 ## TL;DR：修復步驟與建議 1. 優先完成安全升級：使用 nginx.org 官方 Open Source 包的， Stable 1.30 分支至少升級到 1.30.6 ； Mainline 1.31 分支至少升級到 1.31.7 ，截至核驗日建議直接使用最新 1.31.8 。這是兩個獨立的修復門檻，不能單純地以數字大小跨分支比較。 [S1](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-1) [S2](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-2) 2. 發行版安裝按完整軟體包版本驗收： Ubuntu 22.04 / 24.04 / 26.04 / 26.10 已有廠商回補； Debian 13（ trixie ）至少使用 `1.26.3-3+deb13u10` 。 Debian 12（ bookworm ）在核驗時的安全追蹤記錄仍將 `1.22.1-9+deb12u10` 標示為受影響，必須逐 CVE 查看最新狀態，不能據 Debian 13 的公告認定 Debian 12 已修復。 [S13](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-13) [S14](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-14) [S15](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-15) 3. 立即審計五類配置組合： `alias + rewrite + $request_filename` 、 `map` + regex + 變數求值、 `aio + ssi + include virtual` 、 HTTP/3 + `proxy_request_buffering on` 、以及 `ssl_session_cache shared:...` + 自動 TLS Session Ticket 金鑰輪換。是否存在指令不等於漏洞必然可利用；必須結合請求路徑與配置作用域判斷。 [S1](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-1) [S3](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-3) [S4](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-4) 4. 取代全部舊進程與容器：完成 `nginx -t`、服務重新啟動或高可用捲動部署，檢查舊 master/worker 是否徹底退出；僅執行 `nginx -s reload` 無法證明線上已切換到更新後的二進位。 5. 針對風險驗證真實入口：檢查 HTTP/1.1 、 HTTP/2 、 HTTP/3 （若啟用）、反向代理上傳及 API 請求體、 mTLS 證書認證、 SSI 頁面和訪問日誌。記錄每個實際入口的軟體包來源、版本、鏡像摘要、運行過程及驗證結果。 6. 暫不能升級時先移除觸發條件：停用不必要的 SSI / AIO 或 HTTP/3 ，重構脆弱的 `alias` / `rewrite` / `map` 變數引用；涉及 mTLS 的實例可評估臨時 `ssl_session_tickets off;` 。 WAF 、 ASLR 、限流和移除高風險指令只涵蓋部分攻擊條件，不能取代正式修補程式。 [S3](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-3) [S4](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-4) [S8](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-8) [S12](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-12) ## 1. 漏洞概覽與風險判斷 NGINX 於 2026 年 10 月 14 日發布 1.30.6 （ Stable ）與 1.31.7 （ Mainline ），同時修復五項安全性問題。其中三項為堆溢出或釋放後使用， F5 在 CVSS v4.0 標準下為其分別打出 9.2 / Critical；另外兩項涉及 HTTP/3 請求完整性和 TLS 客戶端證書認證邊界。 [S1](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-1) [S2](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-2) [S3](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-3) 評級差異需要明確區分：nginx.org 官方安全清單將本批五項全部標為 `medium`，而 F5 的 CVSS v4.0 與部分國家級安全機構將三項內存級安全機構將三項內存級安全機構將三項內存級安全機構將三項內存級安全機構將三項內存級安全機構將三項內存級安全機構 列為內存級安全機構。這不是五項漏洞都可以無條件遠端執行程式碼；真實攻擊也受到 NGINX 配置、流量可及性及某些不可由攻擊者控制的條件約束。可利用記憶體破壞與穩定可靠的 RCE 是不同證據層級。 [S1](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-4) | CVE | 技術問題與典型觸發條件 | 核心影響 | 評價與處置 | | -------------- | -------------------------------------------------------- | ------------------------------------------- | ------------------------------ | | CVE-2026-15176 | `alias` 路徑映射 + `rewrite` 改變 URI + 求值 `$request_filename` | 堆緩衝區溢出，Worker 崩潰；特定條件下潛在 RCE | F5 CVSS v4.0 9.2；優先檢查 | | CVE-2026-93479 | HTTP/Stream 腳本求值，特別是 `map` 正規捕捉與根目錄、日誌變數交叉引用 | 預留緩衝區被覆蓋，堆溢位；特定條件下潛在 RCE | F5 CVSS v4.0 9.2；屬於先前修復後的回歸風險 | | CVE-2026-97205 | SSI 虛擬包含與 AIO/非同步操作；未完成操作計數溢出 | Use-After-Free，Worker 崩潰、記憶體破壞；潛在 RCE | F5 CVSS v4.0 9.2；需非預設配置 | | CVE-2026-95101 | HTTP/3 未知幀跨緩衝區分片，代理請求體緩衝開啟 | 錯誤將非 DATA 位元組注入上游請求體，可能繞過請求體大小限制 | 此漏洞影響請求完整性。它本身不提供遠端程式碼執行（RCE）。 | | CVE-2026-97629 | 共用 TLS Session Cache、自動金鑰輪替與 Worker 金鑰鏡像 | Session Ticket 偽造；受影響的 mTLS 服務可能發生用戶端憑證認證繞過 | 對證書認證型 API 的業務影響尤需關注 | 上述 CVSS 分數由 F5 採用 v4.0 給出；同一漏洞在 CVSS 3.1、nginx.org 自有等級與發行版評分中可能顯示不同程度的嚴重性評分。 [S1](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-4) ### 1.1 風險應按業務部署而不是按 CVE 分數機械排序 | 部署形態 | 重點排查點 | 處置優先建議 | | ------------------------------------- | ------------------------------------------------------ | -------------- | | 公網反向代理，有自訂 `rewrite`、`alias`、複雜 `map` | CVE-2026-15176、CVE-2026-93479 以及 5—7 月的 rewrite/map 漏洞 | P0：立即審計並更新 | | 以客戶端憑證作為唯一或主要入口鑑權的 API / 管理面 | CVE-2026-97629 的 Session Ticket 與共享快取配置 | P0：立即確認認證邊界及更新 | | 外部提供 HTTP/3 上傳、狀態變更介面、交易類別 API | CVE-2026-95101，尤其是請求體被代理到後端 | P0/P1：依業務重要性安排 | | SSI 動態頁面或非同步檔案 I/O | CVE-2026-97205 | P1：確認組合條件，盡快修復 | | 僅靜態頁 + 簡單 HTTP/1.1/2 反向代理 | 仍需審計配置和版本，但部分 CVE 條件可能缺失 | P1：列入緊急安全升級窗口 | | 使用已退役 Kubernetes 社群 ingress-nginx | 專案停止安全維護，風險不限於這五項 CVE | 單獨制定控制器遷移計劃 | P0/P1 是本文針對公網暴露程度與認證敏感度給予的運維處置建議，並非官方 CVSS 分級，也不應取代企業內部資產與變更風險評估。 ### 1.2 影響邊界與攻擊權限 本批核心漏洞主要處於 NGINX Data Plane：攻擊入口是客戶端連線與請求、實際影響通常發生在 Worker 進程。若符合記憶體破壞的可用條件，程式碼執行權限一般受到此 Worker 的運作使用者、容器約束、Linux capability、掛載及網路權限限制；潛在 RCE 不自動等於 root 或宿主機接管。 [S4](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-4) 但即便流程非特權，仍可能接觸代理憑證、憑證私鑰所在可讀檔案、上游服務令牌、臨時檔案、內部 API 及可達網路。對 mTLS 而言，認證繞過本身可能就是嚴重業務後果，不必同時具備程式碼執行。 ## 2. 成因分析 ### 2.1 理解 NGINX 中三個容易出錯的邊界 NGINX Worker 是常駐的事件驅動進程，維護請求狀態、非同步操作及協定解析器。此次漏洞集中體現出三個工程層面的限制： 1. 變數求值與記憶體尺寸必須一致：`rewrite` 改變請求 URI 後，路徑映射必須與目前有效 `location` 一致；當腳本解釋器計算變數長度時，寫入空間必須覆寫實際輸出及保留區。 2. 非同步操作必須延長請求記憶體的生命週期：有未完成的檔案讀寫、快取等待或執行緒任務時，不能把相關請求記憶體池提前釋放。 3. 協定狀態與安全狀態不能混用或遺漏：HTTP/3 未知幀跳過的長度不能被當作 DATA 請求體長度；TLS Session Ticket 輪換時所有參與驗簽的密鑰槽位必須正確初始化、同步。 以下內容以 NGINX 上游修復提交與廠商公告為依據，解釋可觸發的失敗機制；範例片段用於分析，不是可直接用於修復生產環境的完整程式碼。 [S5](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-9) ### 2.2 CVE-2026-15176：`alias` 與重寫 URI 的路徑對映失效 在 NGINX 中，`location` 匹配與 `alias` 決定實際檔案路徑；`rewrite` 則可能修改目前請求 URI。一旦 URI 已被改寫，原來用於匹配的 `location` 路徑映射假設可能不再成立。 受影響的處理路徑在 `ngx_http_map_uri_to_path()` 中檢查 `alias` 狀態時，沒有充分檢查請求是否已經被重寫。當配置在改寫後繼續求值 `$request_filename`，可能以不符合目前 URI 狀態的假設建構路徑，最終觸發堆記憶體越界寫入。 [S5](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-5) 典型組合（僅作為配置審計反例，不建議部署）： ```nginx # 仅用于识别风险模式：不是修复配置 location /foo/ { alias /srv/alias-root/; rewrite ^/foo/.*$ /new-path; return 200 $request_filename; } ``` 危險不限於 `return`：`set`、`if`、`add_header`、`log_format` 等若在相同請求流程中觸發 `$request_filename` 求值，也需要稽核。範例中的 `return` 僅讓此狀態路徑容易看清，不能用它推斷所有生產配置都會產生溢位。 [S5](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-10) 攻擊後果：構造請求可能造成 Worker 重啟或服務中斷；在 ASLR 被關閉或可被繞過等條件下，存在潛在 RCE。上游修補程式的核心是拒絕在不再有效的 `alias` 上下文中完成重寫後的 URI 路徑映射，而不是簡單地擴大某個緩衝區。 [S5](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-10) ### 2.3 CVE-2026-93479：腳本求值中「預留空間」與真實變數長度錯配 NGINX 的 HTTP 和 Stream 模組都有將字面字串和變數值拼接成結果字串的腳本求值器。應用範例包括 HTTP 文件根路徑、存取日誌路徑，以及 Stream 中的變數表達式。 某些 `map` + 正規表示式的配置允許捕獲值在 `map` 結果變數求值之前被其他表達式讀取。結合預留長度的腳本執行方式，舊實作會把 `len` 預留空間提前計入求值的長度累加器，使後續寫入指標計算與緩衝區邊界不再一致。在特定變數求值序列中，後續字串寫入可能會覆蓋預留區域，造成堆溢位。 [S6](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-6) | 參與元素 | 為什麼值得關注 | | --------------------- | ----------------------------------------------- | | `map` 中的 regex | 捕捉變數求值可能有獨立的生命週期與快取行為 | | `$1`、`$2` 等匿名捕獲 | 易被其他正規或表達式覆蓋，難以追蹤所有權 | | `root` 中的變數 | 觸發路徑建置時的腳本執行和緩衝區預留 | | `log_format` / 動態日誌路徑 | 在請求後期可能觸發相同類型的求值 | | `stream` 中的腳本表達式 | 上游修復同時修改 `ngx_stream_script_run()`，不能只審 HTTP 模組 | 重要的回歸關係：此漏洞相關程式碼與先前修復 CVE-2026-42533 的變更有關。 Debian 13 的官方 DSA 明確指出，受影響的程式碼是透過較早的安全回補引入 trixie 套件的。因此，「已安裝 7 月 `map` 漏洞修補程式」並不等於已經覆蓋 10 月的 CVE-2026-93479；應檢查完整安全修復鏈。 [S6](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-17) 這裡的潛在 RCE 風險與記憶體保護環境有關，不應宣稱僅含 `map` 正則就一定能夠被匿名攻擊者利用。 [S11](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-11) ### 2.4 CVE-2026-97205：AIO 未完成操作計數迴繞造成 Use-After-Free 本漏洞不是簡單的“開啟 SSI 就有 UAF”，關鍵在於主請求所持有的非同步操作引用計數。 NGINX 使用 `r->main->blocked` 追蹤尚未結束的非同步處理，舊實作中它是 8 位元計數；某些路徑沒有在增加計數之前進行上限檢查。當同一主請求累積 256 個未完成操作時，計數可能從 255 迴繞到 0。後續流程會錯誤地認為沒有阻止請求釋放的非同步操作，從而釋放仍被任務引用的請求記憶體池。 [S7](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-7) 失敗過程可分為： 1. 啟用了相關非同步 I/O/執行緒路徑，SSI 頁面透過 `include virtual` 引入多個子請求或讀取操作。 2. 某一主請求的未完成操作累加到計數欄位的表示上限。 3. 8 位元計數迴繞，錯誤地表示為「沒有掛起操作」。 4. 請求記憶體池被釋放，而檔案讀取、快取等待或執行緒任務的回呼仍保留其中的參考。 5. 後續異步完成回調存取已釋放的內存，產生 UAF、Worker 崩潰或潛在內存破壞。 官方修復在請求頭檔加入 `NGX_HTTP_MAX_BLOCKED 250`，並在輸出過濾器、快取讀取與上游執行緒路徑加入限制；達到閾值時，有同步路徑的操作改為同步完成，不能安全處理的則拒絕繼續增加掛起任務。 [S7](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-7) 適用性判斷：必須評估 SSI、AIO、虛擬包含、子請求及相關非同步操作能否在同一請求鏈中組合發生。這些通常不是預設​​普通靜態代理配置。 `aio off;` 或 `ssi off;` 可移除特定觸發要素，但應先確認業務功能依賴。 [S4](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-25) ### 2.5 CVE-2026-95101：HTTP/3 未知影格與 DATA 請求體的狀態混淆 HTTP/3 幀解析器必須區分 `DATA` 幀（需要傳遞給 HTTP 請求體處理流程）和應跳過的未知幀。未知幀的長度在跨網路緩衝區區分片時也必須準確保留。 舊實現的 `ngx_http_v3_parse_data()` 在跳過未知幀時使用了 `st->length` 字段保存“剩餘待跳過字節數”，而請求體過濾器把同一字段解釋為“剩餘 DATA 載荷長度”。如果未知幀恰好跨多次解析調用，解析中斷後下一批位元組可能被誤認為請求體的一部分。 [S8](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-8) 由此出現兩類風險： - 請求體注入：客戶端提交的非 DATA 訊框載重可能傳送給上游應用，改變後端實際接收的資料。 - 大小限制繞過：`client_max_body_size` 等限制的預期檢查集中在 DATA 路徑，錯誤轉換的內容可能繞過對應核驗。 官方描述的典型觸發場景為 `ngx_http_v3_module` 接收 HTTP/3 請求、並且轉發時 `proxy_request_buffering on`。代理請求體緩衝在 `ngx_http_proxy_module` 中預設為啟用。因此，開啟 HTTP/3 的反向代理應優先核對，不宜僅因為沒有明確寫出 `proxy_request_buffering on;` 就認定不存在觸發條件。 [S8](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-18) 此漏洞的直接後果屬於後端請求完整性與安全邊界變化，不是在 NGINX 核心直接完成 RCE 的等價表述。其最終業務影響取決於上游如何解析和信任這些位元組。 [S24](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-24) ### 2.6 CVE-2026-97629：TLS Ticket 輪換遺漏第三個密鑰插槽 在受影響配置中，NGINX 可以透過共享記憶體快取自動產生和輪換 TLS Session Ticket 金鑰，使多個 Worker 能處理同一批票據。 相關同步邏輯為每個 Worker 分配 3 個密鑰槽位，解密回調也會遍歷這些插槽；但舊實現每次只從共享記憶體複製 2 個密鑰槽位，導致第 3 個槽位的密鑰名稱、HMAC 密鑰和 AES 密鑰可能保持未初始化狀態。若某個票據的金鑰標識被這個狀態匹配，可能以未初始化的金鑰材料進行驗簽與解密，從而形成偽造 TLS 會話的路徑。 [S9](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-9) 高風險部署組合通常是： ```nginx # 仅为排查触发条件所示：共享缓存本身不是恶意配置 ssl_session_cache shared:SSL:10m; # 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制 ``` 此漏洞最嚴重的業務結果是：在以 `ssl_verify_client on;` 等方式使用用戶端憑證認證（mTLS）的服務上，偽造復原工作階段可能繞過用戶端憑證驗證。攻擊成功也受不可控條件限制；僅使用普通服務端 HTTPS 憑證、沒有客戶端憑證認證的站點，不應被錯誤描述為「攻擊者能夠繞過整個網站登入」。 [S9](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-12) 這是一個 TLS 會話認證狀態問題，與服務端 TLS 私鑰是否被破解、公共 CA 根憑證是否受影響無關。 [S24](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-24) ### 2.7 如何理解 DoS、RCE、認證繞過與已知利用 - DoS：記憶體錯誤導致 Worker 崩潰或大量重啟。是否造成整體不可用與流量壓力、進程重啟能力、連接維持時間和高可用架構有關。 - 潛在 RCE：部分公告指出 ASLR 關閉或被繞過時存在代碼執行可能，不代表已披露可穩定通用地執行命令的公開攻擊鏈。 [S4](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-4) - 請求注入 / 認證繞過：可能直接改變受保護業務狀態或請求內容，不能因為其不直接獲得 shell 就忽略。 - 已發現攻擊嘗試：2026 年 5 月的 CVE-2026-42945 有野外利用活動相關報告；不應把這條歷史事實直接推斷為 10 月五項 CVE 都已遭大規模成功利用。 [S23](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-23) ## 3. 修復版本與補丁選擇 ### 3.1 NGINX Open Source 官方修復基線 | 上游分支 | 首個覆蓋 10 月五項漏洞的正式版本 | 截至 2026-10-27 的建議 | | ------------------------ | ------------------ | -------------------------------- | | Stable 1.30.x | 1.30.6（2026-10-14） | 至少安裝 1.30.6，後續安全版本繼續跟進 | | Mainline 1.31.x | 1.31.7（2026-10-14） | 1.31.8（2026-10-21） | | 更早的 NGINX Open Source 分支 | 不能僅依據「曾打過舊漏洞補丁」判定 | 優先遷移至受維護分支；否則要求廠商提供逐 CVE 的正式回補證據 | 這些是 nginx.org 上游原始碼/官方分支 的版本結論，不應直接拿來否定發行版廠商提供的舊版回補安全包。 `1.31.6` 即使數值大於 `1.30.6`，仍低於主線分支的修復門檻。 [S1](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-2) ### 3.2 五項 CVE 的上游受影響範圍 以下範圍依 nginx.org 安全性公告原文列示，需結合「目前運行分支」與「實際設定路徑」來理解： | CVE | 上游標記受影響版本 | 官方標記已修復版本 | | -------------- | ------------------------------- | -------------------------- | | CVE-2026-15176 | `0.1.29–1.31.6` | `1.30.6+` 或 `1.31.7+`，各分支內 | | CVE-2026-93479 | `1.30.0–1.30.5`，`1.31.2–1.31.6` | 同上 | | CVE-2026-97205 | `0.8.11–1.31.6` | 同上 | | CVE-2026-95101 | `1.25.0–1.31.6` | 同上 | | CVE-2026-97629 | `1.23.2–1.31.6` | 同上 | 要特別注意，CVE-2026-93479 有引入版本限定；不能把所有舊 NGINX 版本都概括為「受此迴歸漏洞影響」。但較舊版本即使不受這次迴歸影響，也可能仍受更早的 `map` 正規漏洞 CVE-2026-42533 影響。 [S1](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-1) ### 3.3 Ubuntu：發行版回補版本（USN-8955-1） Canonical 2026 年 10 月 26 日的 USN-8955-1 為四個 Ubuntu 版本提供了安全更新：[S13](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-13) | Ubuntu 版本 | `nginx` 及同源包修復版本 | 說明 | | --------- | --------------------- | ---------------------- | | 22.04 LTS | `1.18.0-6ubuntu14.22` | 屬於廠商回補；上游版本號仍顯示 1.18.0 | | 24.04 LTS | `1.24.0-2ubuntu7.19` | 同上 | | 26.04 LTS | `1.28.3-2ubuntu1.12` | 同上 | | 26.10 | `1.30.4-7ubuntu1.1` | 同上 | 公告包含 `nginx-core`、`nginx-extras`、`nginx-full`、`nginx-light` 等同源套件的相應修復版本。不要從 `nginx -v` 只顯示的上游部分得出是否修復的結論。例如 Ubuntu 24.04 的 `1.24.0-2ubuntu7.19` 已有這次廠商補丁，但任意來源的 `1.24.0` 並不天然安全。 Ubuntu 官方也明確標註， CVE-2026-95101 在該公告中僅影響 Ubuntu 26.04 / 26.10 ， CVE-2026-97629 僅影響 Ubuntu 24.04 / 26.04 / 26.10 。此處為Ubuntu 自身打包及功能範圍，不可直接推及其他發行版。 [S13](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-13) ### 3.4 Debian：版本間差異必須單獨核查 Debian 的 DSA-6575-1（2026-10-21）涵蓋本批五項 CVE，並確認 Debian 13 / trixie 的 `nginx` 修復版本為： ```text 1.26.3-3+deb13u10 ``` 然而，截至本報告核驗時，Debian Security Tracker 對 Debian 12 / bookworm 的 `1.22.1-9+deb12u10` 仍標示為 vulnerable。因此： - Debian 13 按 DSA-6575-1 更新並驗收即可。 - Debian 12 必須逐項檢查目前 Security Tracker 或 ELTS 廠商提供的安全修復；在公告尚未確認修復前，不要憑 `apt upgrade` 成功便宣布這五項已全部修復。 - Debian 原始碼包可能攜帶獨立於 nginx.org 版本號的補丁集。對於自訂構建，需要核對完整源碼包修復集合，不能照抄單一上游提交就認為完成。 以上區分以 DSA 與 CVE 追蹤記錄為依據。 [S14](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-16) ### 3.5 NGINX Plus、njs 與 Ingress Controller | 產品/組件 | 安全選擇與驗證重點 | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NGINX Plus（商業版） | 以 F5 對應 Plus 分店公告和升級說明為準。核驗時最新 CR 為 `PLS.37.2.0.1`，LTS 安全建構成 `PLS.37.0.7.1`；Plus 的版本與包含的回補不能直接以 Open Source 的 1.30/1.31 門檻取代。 [S19](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-19) | | njs / ngx\_http\_js\_module | 2026-10-14 發表 `njs 1.0.2`，修正 CVE-2026-101019 與 CVE-2026-101025；若正在使用 njs，要同時核對模組與 NGINX 的相容性。 [S20](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-20) | | F5 NGINX Ingress Controller / Gateway Fabric | 與 NGINX 核心是關聯但獨立的軟體發行鏈。以各自控制器、鏡像及發行說明修復相關漏洞，不能只取代 Pod 內的一個 NGINX 二進位。 | | Kubernetes 社群 `kubernetes/ingress-nginx` | 該專案在 2026 年 3 月退役，不再提供新的安全維護。應規劃遷移到受維護控制器或 Gateway API，而非把其發行版號誤認作 F5 NGINX Ingress Controller。 [S21](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-21) | ### 3.6 實際上應選擇哪一種 Patch | 部署形態 | 推薦做法 | 修復證明 | | ----------------------------------------- | ------------------------------------- | ---------------------------------- | | nginx.org 官方 DEB/RPM 包 | 升級到所屬上游分支已修復版本 | `nginx -v/-V`、包來源、官方安全公告 | | Ubuntu/Debian 官方倉庫 | 安裝廠商安全軟體包 | 完整包版本 + 廠商 USN/DSA + CVE 狀態 | | RHEL/Alma/Rocky/SUSE/其他發行版 | 依具體發行版安全公告及套件版本升級 | 對應廠商 CSAF/公告，不能套用 Ubuntu/Debian 版本 | | 官方或自訂容器鏡像 | 重新建構或拉取經核驗的修復鏡像，滾動替換 | 鏡像摘要、建置 SBOM、運行中 Pod/容器鏡像 ID | | 自編譯 NGINX、OpenResty、Tengine 或打過第三方模組補丁的版本 | 優先採用維護者完整安全版本；必要時針對目標原始碼樹進行受審查的修補程式回補 | 五項漏洞修復內容、ABI/模組相容、單元及業務回歸 | OpenResty 和 Tengine 是不同發行系統；此表僅說明驗證方法，不表示其全部版本都與標準 NGINX 同時受影響，也不能無條件地套用上游程式碼修補程式。 ## 4. 正式修復流程 ### 4.1 盤點真實接收外部流量的實例 至少為每個入口整理： - 網域名稱、負載平衡/CDN/邊緣代理連結、來源站暴露方式及所使用的網路協定。 - NGINX 產品（Open Source、Plus、Ingress 等）、完整版本、套件倉庫來源、鏡像摘要。 - `nginx -V` 顯示的建置模組和編譯參數；有無 njs、Lua、OpenResty、第三方動態模組。 - 真正運作的 master/worker PID、服務單元/容器/Pod、副本和工作節點。 - 實際生效的 `http`/`stream`、`server`、`location`、`include` 設定。 - 是否啟用 HTTP/3、mTLS、SSI/AIO、動態日誌路徑、複雜 `map` 和正規擷取。 不要只檢查預設的 `/etc/nginx/nginx.conf`。生產環境常透過 `include` 載入多份網站、TLS 和模組配置，也可能有多個 NGINX 安裝路徑或多個代理層。 ### 4.2 檢查版本和編譯訊息 ```bash # NGINX 版本及构建选项 nginx -v nginx -V 2>&1 # Linux：查看实际运行的 NGINX 进程 ps -eo pid,ppid,user,comm,args | grep '[n]ginx' # Debian / Ubuntu：查看完整已安装包版本、来源 apt-cache policy nginx # 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包 dpkg-query -W 'nginx*' 2>/dev/null # RPM 系：以实际安装包及仓库公告为准 rpm -qa | grep '^nginx' ``` `nginx -V` 只能說明命令列路徑下二進位的建置情況，並不能單獨證明目前線上 Worker 已經載入它。同時注意 `nginx -v` 可能隱藏發行版完整建置字尾；應使用系統套件管理器或供應鏈記錄確認。 ### 4.3 匯出生效配置並進行第一輪靜態篩檢 `nginx -T` 會測試配置並轉儲合併後的配置，輸出可能含有認證憑證、金鑰路徑、內部主機名稱等敏感資訊。建議在受控終端以 root 權限、私有檔案權限保存，不要將原始檔案貼到公開工單： ```bash sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log' sudo grep -nE \ 'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \ /root/nginx-effective.conf ``` 這只是候選路徑定位器，不是可靠的 CVE 自動判定工具： 1. `grep` 無法判斷變數是否位於相同 `location` 或同一個請求求值鏈，也無法推導出配置繼承關係。 2. `proxy_request_buffering on`、部分快取及票據配置存在預設值，不寫出對應指令不等於風險消失。 3. 反向代理、CDN、容器側車或控制器產生的配置可能與手動檢查的檔案不同。 4. `NGINX Plus` 與動態模組的特性可能需要使用各自的官方管理工具才能確認。 ### 4.4 透過可信任頻道部署修復 Debian/Ubuntu（官方發行版倉庫）： ```bash sudo apt-get update apt-cache policy nginx # 升级发行版仓库中已经安装的 NGINX 及相关包； # 先确认 Candidate 属于修复版本，再执行升级。 sudo apt-get install --only-upgrade nginx # 对实际安装的 nginx-core / nginx-full / nginx-extras 等包 # 确认它们的版本和依赖一同达到厂商修复要求。 dpkg-query -W 'nginx*' 2>/dev/null ``` 這組指令不能憑空產生尚未提供的安全性修復。特別是 Debian 12，升級後的包若仍被安全追蹤系統認定為 vulnerable，需要額外的廠商修復、隔離或遷移措施。 [S13](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-15) nginx.org 官方套件： ```bash # 先确认仓库来自 nginx.org、目标分支和候选版本 apt-cache policy nginx # 经变更审批后再执行对应仓库的升级命令 sudo apt-get install --only-upgrade nginx ``` 若使用自編譯、OpenResty、Tengine 或 NGINX Plus，則採用對應維修者支援的修補版本，請勿混用 nginx.org、發行版及第三方倉庫軟體套件。應保留原始二進位/鏡像、配置、簽章及可回滾部署清單。 容器/Kubernetes：更新不可變鏡像，記錄鏡像 digest，經灰度發布將舊副本全部滾動替換。 `kubectl rollout status` 只能證明部署控制器的發佈完成；仍應進一步核對鏡像摘要、入口路由與異常副本。 ### 4.5 驗證配置並取代舊 Worker ```bash sudo nginx -t # 按服务实际名称、主机高可用和变更窗口执行重启 sudo systemctl restart nginx sudo systemctl status nginx --no-pager # 核查真正存在的 master / worker ps -eo pid,ppid,user,comm,args | grep '[n]ginx' ``` 不要把 `nginx -s reload` 視為安裝新二進位的充分驗收動作：普通配置 reload 常由仍在運行的舊 master 創建 Worker，不能保證進程映像替換。 NGINX 有專門的線上二進位升級機制，但需要額外操作和稽核；若沒有成熟的流程，建議透過高可用切流後重新啟動服務或捲動更新實現安全切換。 [S22](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-22) 如果透過 `systemd` socket、容器入口腳本或多套安裝管理 NGINX，應檢查實際啟動目標和進程路徑，而不是直接假設 `systemctl restart nginx` 覆寫所有實例。 ### 4.6 從真實外部入口驗收並做業務回歸 建議至少執行： - 普通 HTTPS、重寫路由、靜態資源以及 `alias` 映射頁面是否正確。 - 正規 `map` 分流、變數根路徑、存取日誌路徑、SNI/憑證路由、Stream 代理程式是否正確。 - HTTP/3（啟用時）的普通上傳、分塊上傳、API 請求及上游體積限制是否仍與預期一致。 - mTLS：合法證書請求應成功；缺失、過期或無權證書應仍被拒絕，TLS 恢復/重連不應意外改變權限。 - SSI 頁面和非同步檔案存取是否正常；錯誤日誌無異常的請求記憶體引用或重複 Worker 崩潰。 - 流量切換後，舊版本進程和舊鏡像副本應已退出。 測試須在自有或獲授權環境進行。正常請求冒煙測試不能單獨證明記憶體漏洞已被修復；最終還需以供應商修復版本、源碼補丁和運行時實測共同驗收。 ## 5. 無法立即升級時的緩解措施 本節是風險降低方案，不是補丁替代品。所有臨時配置變更應備份、執行 `nginx -t`、分批發布，必要時能快速回退。 [S3](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-4) ### 5.1 按外部暴露優先控制流量 優先降低無法及時升級的服務的攻擊面：對管理面和內部 API 增加可信任來源存取控制、上游網路隔離或短期下線；為高風險入口加上連線、請求體和速率限制；確保來源認證發生在進入相關 NGINX 請求處理鏈之前。需注意，多數本次漏洞本身位於 NGINX 資料面內部，傳統 WAF 規則可能無法準確判斷自訂配置觸發條件。 ### 5.2 `alias` / `rewrite`：避免改寫後求值 `$request_filename` 建議檢查並調整： - 盡量不要在使用 `alias` 的 `location` 中同時進行會改變 URI 的 `rewrite`。 - 避免在 URI 已改寫但尚未完成正確位置匹配時使用 `$request_filename`。 - 檢查 `return`、`set`、`if`、`add_header`、存取日誌格式及包含檔案中的間接變數參考。 - 業務上允許時使用清晰的 `root`/`try_files`/獨立 `location`，但僅將 `alias` 改成 `root` 也可能改變文件路徑驗證語義，必須逐條路徑驗證。 不要直接複製網路上的通用「安全 rewrite 範本」覆蓋現有配置。不同 `location` 前綴和重寫目標會導致路徑拼接意義完全不同。 [S5](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-5) ### 5.3 `map` / Regex：降低捕捉變數狀態混合 建議優先採用具名捕獲並限制其傳播範圍，而不是讓 `$1` 等匿名捕獲跨不同正則處理流程長期復用。例如： ```nginx # 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整 map $host $tenant_root { default /srv/www/default; ~^(?[a-z0-9-]+)\.example\.net$ /srv/www/$tenant; } ``` 此片段僅演示變數所有權更容易審計的結構；並不意味著它已被證明能獨立消除所有 CVE-2026-93479 的觸發路徑。尤其要審核擷取變數是否被其他 `root` 或 `log_format` 事先引用，以及是否有 `volatile`、動態路徑和相互依賴的求值鏈。 F5/CERT 建議使用具名捕獲、將使用範圍限定在對應正規匹配配置中作為短期緩解。 [S3](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-6) ### 5.4 AIO + SSI：關停不必要的功能組合 對不需要 SSI 或非同步檔案 I/O 的伺服器/路徑，可採用： ```nginx # 在适当的 http/server/location 上下文中配置 ssi off; aio off; ``` 從漏洞觸發條件來看，關閉二者之一通常足以移除描述的特定鏈條；同時關閉僅適用於業務確實不依賴該能力的場景。檢查 `include virtual`、子請求、快取及執行緒池行為；在反向代理負載較高時，關停 AIO 可能改變延遲和 I/O 效能。 [S7](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-7) ### 5.5 HTTP/3 請求體注入：必要時暫時關閉入口 停用涉及 HTTP/3 的 `quic` 監聽，取消對外宣告 HTTP/3 的 `Alt-Svc` 響應頭，並核對邊緣層/負載平衡器是否仍把 QUIC 請求直接送入未修復的 NGINX ： ```nginx # 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen server { listen 443 ssl; # 保留 HTTPS/TCP 入口 # 对支持新版语法的构建，可在此使用 http2 on; # 删除原有的 listen 443 quic reuseport; # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项） # 其余证书、server_name、location 等配置保持不变 } ``` 以上只是變更差異說明，不是可以單獨啟用的完整 server 設定。 HTTP/2 的設定語法與 NGINX 版本有關；如需保留 HTTP/2，應依對應版本使用 `http2 on;` 或現有有效語法，並以 `nginx -t` 檢查。部署前必須和現有 server 配置合併，而不是原樣用這一節替換整段。同時檢查 UDP 443 防火牆、CDN/前置代理的 HTTP/3 終止位置及客戶端回退路徑。 另一類短期緩解是對受影響代理路徑使用 `proxy_request_buffering off;`，但這會改變上游請求體流式發送、失敗重試和一些上傳工作流程的行為；僅在充分測試並確認該指令確實命中受影響的 HTTP/3 代理路徑後採用。 [S8](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-18) ### 5.6 TLS Session Ticket：優先保護 mTLS 認證邊界 若無法升級且實例依賴共用會話快取 + 自動票據金鑰輪換，可評估： ```nginx # 在 nginx http/server 适当作用域进行配置 ssl_session_tickets off; ``` 這樣可以關閉 TLS Session Ticket 機制，從而移除該漏洞描述的票據偽造路徑；但可能會影響會話恢復效能。不能只關掉 mTLS 用戶端憑證驗證來“避免漏洞”，那會直接刪除原有認證邊界。 [S9](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-12) 也可由專業 TLS 管理流程使用明確 `ssl_session_ticket_key` 檔案及安全輪調來避開自動產生條件，但金鑰保管、全節點分送、輪替及舊票據生命週期都需謹慎稽核。不建議為臨時應急在普通 Web 配置或腳本中硬編碼一個長期復用的密鑰。使用 mTLS 的關鍵服務，應額外監視 TLS 會話恢復行為與無憑證存取拒絕情況。 [S12](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-12) ### 5.7 作業系統與邊界防護的作用 ```bash # Linux：常见值 2 表示进程地址空间随机化处于完整启用状态 sysctl kernel.randomize_va_space ``` ASLR 、非 root Worker 、容器唯讀檔案系統、最小檔案權限和網路存取隔離均可降低潛在 RCE 的最終影響；但 ASLR 不能修復堆越界或 UAF ，也不能保證 Worker 不崩潰。 WAF 、限流和請求體大小限制也無法覆蓋 TLS [S4](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-4) ### 5.8 常見迷思：這些操作不足以視為完成修復 | 常見操作 | 為什麼不足 | | -------------------------- | -------------------------------------------- | | “nginx -v 看著比較新” | 未檢查所屬分支、發行版完整回補版本及線上流程 | | “只升級了內網其中一台” | 舊 Worker/舊容器/舊 CDN 源站實例仍接收請求 | | “網站不使用 PHP/動態程式碼” | 缺陷發生在 NGINX 核心路徑或協定解析，不依賴 PHP 執行 | | “打開 WAF / Cloudflare 已經夠了” | WAF 無法證明攔截所有 NGINX 設定依賴型記憶體缺陷或 TLS 恢復缺陷 | | “已經開啟 ASLR” | 只是利用難度緩解；DoS 與請求注入仍然可能 | | “HTTP/3 不對公網暴露，所以完全不需要升級” | 其他四項 CVE 仍需獨立評估；且可能存在隱藏源站直連 | | “7 月的 `map` 漏洞已經修復” | 10 月 CVE-2026-93479 涉及後續腳本求值回歸問題 | | “禁用快取能夠解決全部問題” | 只影響部分 TLS 快取或 AIO 場景，不涵蓋 alias、script、HTTP/3 | ## 6. 官方 Patch 的實現思路與審閱重點 本節直接對應 NGINX 上游 2026 年 10 月修復提交。程式碼只摘取代表性的變化，用於幫助審查、核驗廠商回補方向與理解防禦原則，不保證可以脫離原補丁獨立編譯。若確實需要維護自編譯版本，應檢查完整提交、上下文差異與對應測試，並優先採用已發布的完整版本。 [S5](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-9) ### 6.1 CVE-2026-15176：將 URI 已改寫納入 `alias` 路徑對映拒絕條件 上游提交修改了 `src/http/ngx_http_core_module.c` 中的 `ngx_http_map_uri_to_path()`： ```diff - if (alias && !r->valid_location) { + if (alias && (!r->valid_location || r->uri_changed)) { ``` 審查重點：不能在 URI 已變更但 `alias` 對應位置語意不再可靠時繼續計算檔案系統路徑。這是對前置狀態約束的補強，不是簡單檢查請求 URI 是否有非法字元。 [S5](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-5) ### 6.2 CVE-2026-93479：正確區分輸出資料長度與保留長度 上游提交同時更新 `src/http/ngx_http_script.c` 與 `src/stream/ngx_stream_script.c`，核心意圖可歸納為： ```diff - n = len; + n = 0; /* ...计算实际脚本输出长度... */ - value->len = n; - value->data = ngx_pnalloc(pool, n); + value->len = n + len; + value->data = ngx_pnalloc(pool, n + len); ``` 其中 `pool` 是用來說明兩個模組都執行記憶體分配的示意參數名稱；實際 HTTP 與 Stream 原始檔的分配表達式有所不同。核心變化是先計算真實腳本輸出長度，再將預留長度加入最終分配，避免寫入佔用預留空間。 [S6](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-6) 審計回補時要同時覆寫 HTTP/Stream 的對應求值器；只查 `map` 的設定語法檔不能證明缺陷已修復。 ### 6.3 CVE-2026-97205：為 8 位元非同步操作計數設定安全閾值 上游在 `src/http/ngx_http_request.h` 新增： ```c #define NGX_HTTP_MAX_BLOCKED 250 ``` 並在非同步檔案讀取、快取等待、輸出過濾和線程操作入口增加類似： ```c if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) { /* 使用同步路径，或者拒绝新的异步操作 */ } ``` 審查重點：必須涵蓋會增加 `r->main->blocked` 的所有實際程式碼路徑，不能只是把閾值常數寫在頭檔裡。回補還需要檢查同步回退、非同步回調和錯誤回傳的完整配合，確保不會因為直接拒絕任務而造成死鎖或引用洩漏。 [S7](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-7) ### 6.4 CVE-2026-95101：為未知影格單獨維護 `skip` 狀態 上游在 HTTP/3 解析器狀態結構中新增 `skip` 字段，並進行狀態分離： ```c if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) { st->skip = st->length; st->length = 0; st->state = sw_skip; } /* ... */ rc = ngx_http_v3_parse_skip(b, &st->skip); ``` 關鍵不是“禁止未知 HTTP/3 幀”，而是保證跨多次讀取時，跳過字節數和DATA 載荷長度永遠由獨立狀態管理。審閱時應注意未知影格跨緩衝區分片，以及 `client_max_body_size` 的最終一致性。 [S8](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-8) ### 6.5 CVE-2026-97629：同步完整的 TLS 金鑰槽位數組 上游改動位於 `src/event/ngx_event_openssl.c`： ```diff ngx_memcpy(keys->elts, cache->ticket_keys, - 2 * sizeof(ngx_ssl_ticket_key_t)); + keys->nelts * sizeof(ngx_ssl_ticket_key_t)); ``` 原本鏡像含有三個密鑰槽位，卻只複製了前兩個。改為依實際數組元素數量同步，確保 Worker 的驗票金鑰集合與共享記憶體一致。審閱時也要確認陣列分配、初始化、共用鎖定與輪換邏輯一致，而非僅檢查一次 `memcpy` 長度修改。 [S9](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-9) ### 6.6 為什麼不建議只套用零散補丁片段 這五項修改分別橫跨 `src/http`、`src/stream`、`src/http/v3`、`src/event`，且舊版可能有安全回補和非官方擴充。回補應形成如下核對矩陣： | 檢查對象 | 必須確認的內容 | | ----- | -------------------------------------------------- | | 補丁來源 | 官方提交、匹配目標版本、完整補丁及簽名驗證 | | 原有補丁集 | 與 CVE-2026-42533、發行版回補等歷史修改不衝突 | | 程式碼路徑 | HTTP + Stream 腳本、AIO/線程、HTTP/3、OpenSSL Ticket 都覆蓋到 | | 編譯相容 | OpenSSL、PCRE、模組 ABI、動態模組和連結相依一致 | | 功能回歸 | `alias` 重寫、動態日誌、SSI/AIO、HTTP/3 上傳、mTLS session 恢復 | | 運行時 | 所有 Worker/Pod 都運行已經驗證的新構建，不再殘留舊映像 | 對於維護自身發行版的團隊，建議給每個 CVE 保留可審計的 patch ID、套件版本、建置日誌和迴歸報告；對於普通運維，最穩健的方案仍是安裝供應商完整安全更新。 ## 7. 歷史漏洞回溯、舊分支與其他產品 ### 7.1 2026 年 5—9 月值得同時確認的 NGINX 核心漏洞 許多長時間未更新的 NGINX 實例並不只受 10 月的新問題影響，以下列出近期具代表性的修復節點：[S1](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-2) | CVE | 首次修復發布 | 關鍵風險與需要審計的條件 | | -------------- | ---------------------------------------- | ---------------------------------------------------------- | | CVE-2026-42945 | Stable 1.30.1 / Mainline 1.31.0，5 月 13 日 | `rewrite` 匿名正則捕獲與替換邏輯觸發堆溢出、潛在 RCE；有公開的野外攻擊嘗試報告 | | CVE-2026-9256 | Stable 1.30.2 / Mainline 1.31.1，5 月 22 日 | `rewrite` 中重疊正規捕捉與長度估算導致溢出 | | CVE-2026-42055 | Stable 1.30.3 / Mainline 1.31.2，6 月 17 日 | HTTP/2 到上游或 gRPC 的特定配置、大請求頭條件觸發緩衝區溢出 | | CVE-2026-42530 | Mainline 1.31.2，6 月 17 日 | HTTP/3 Use-After-Free；官方標記受影響範圍 `1.31.0–1.31.1` | | CVE-2026-42533 | Stable 1.30.4 / Mainline 1.31.3，7 月 15 日 | `map` + regex 捕獲變數求值引發堆溢出，後續補丁與 10 月 CVE-2026-93479 存在回歸關聯 | | CVE-2026-60005 | Stable 1.30.4 / Mainline 1.31.3，7 月 15 日 | `ngx_http_slice_module` 特定變數和快取更新條件下記憶體內容洩露 | | CVE-2026-56434 | Stable 1.30.4 / Mainline 1.31.3，7 月 15 日 | SSI 相關 UAF；與 10 月的 AIO 計數漏洞不是同一根因 | | CVE-2026-90439 | Stable 1.30.5 / Mainline 1.31.6，9 月 15 日 | HTTP/3 + 特定 OpenSSL 版本組合的有限堆溢出，主要表現為崩潰/有限內存破壞 | 其他 2026 年公佈的 NGINX Core、 HTTP/2 、charset、SMTP 等漏洞也應依官方安全公告排查；本表有意聚焦與目前 NGINX 公網反代部署最相關、且具有記憶體安全或請求完整性意義的典型事件，不是 2026 年全部 CVE 清單。 [S1](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-1) #### 為什麼特別關注 CVE-2026-42945 有政府機構安全公告記錄針對這項 5 月 `rewrite` 漏洞的野外利用活動及公開利用代碼信息，因此對於在 5 月至今長期未打補丁、同時開放公網複雜正則重寫的實例，除了完成修復，還應額外審查當時的異常 Worker 崩潰、訪問日誌和可疑變差。 [S23](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-23) 「發生了攻擊嘗試」並不自動證明攻擊者已經在每個目標上穩定執行命令；如涉及事件回應，應把入侵指標、進程崩潰與真正的權限提升或持久化證據分開調查。 ### 7.2 舊版或發行版回補應採用的應急策略 NGINX 不同分支有各自的支援週期與不同的漏洞引入時間。不能把新版五項補丁不加審閱地統一打到所有早期原始碼樹。 | 場景 | 推薦策略 | | ------------------------------------ | -------------------------------------------- | | 發行版已公佈完整安全回補 | 使用廠商軟體包，記錄完整包版本；避免替換成不相容的上游裸二進位 | | Debian 12 等暫未涵蓋本批所有 CVE 的受影響發行版 | 提交風險工單、限制外部暴露，查供應商/ELTS 狀態；必要時遷移或使用可驗證的維護發行鏈 | | 已終止上游支援的歷史分支 | 優先遷移到支援版本；若必須短期回補，由維護者評估依賴和修補程式相容、編寫完整測試 | | 自帶 NGINX 分叉（OpenResty、Tengine、客製化閘道） | 先判斷是否包含對應程式碼路徑，再使用分叉維護者安全聲明，不能直接等同上游版本 | | 安全性補丁導致業務功能變化 | 採用灰階、雙版本切流、設定適配；不宜不加隔離地還原公網未修復版本 | ### 7.3 njs、Ingress 與 NGINX Core 的修復邊界 - njs：除了 NGINX 主程序，還需檢查 NGINX JavaScript 模組本身的版本。 `njs 1.0.2` 修正了 2026 年 10 月的 XML 解析記憶體耗盡及帶實體引用屬性的 XML 驗證不一致問題。對於使用 `nginx-saml` 等與 XML 簽章驗證關聯的部署，應進一步閱讀 njs 官方針對插件場景的說明。 [S20](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-20) - F5 NGINX Plus / NGINX Ingress Controller：Plus、控制器及 Gateway Fabric 各自可能帶有額外安全公告、不同打包版本及特有策略漏洞，升級一個層次不等於自動更新另一個層次。 [S19](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-19) - Kubernetes 社群 ingress-nginx：Kubernetes 官方早已公告該控制器於 2026 年 3 月停止維護，其倉庫與 F5 控制器不能混為一談。受影響業務應規劃平滑遷移、驗證 Ingress 註解及 Gateway API 語意差異，而非等待新安全版本。 [S21](https://keendigit.com/zh-hant/insights/nginx-remediation-guide#source-21) ## 8. 驗收標準與後續檢查 建議以下清單作為變更工單的驗收條件： | 專案 | 合格標準 | 可留存的證據 | | ---------- | ---------------------------- | ------------------------ | | 資產與入口覆蓋 | 所有對外及可繞過 CDN 直連的實例均已盤點 | 域名、LB、IP、Pod/容器清單 | | 包來源與修復範圍 | 使用經確認覆蓋全部適用 CVE 的版本 | 上游安全公告、USN/DSA、套件版本、鏡像摘要 | | 舊進程退出 | 所有舊 master/worker/容器已替換 | PID/啟動時間、捲動部署狀態、運行中映像 | | 配置審計 | 高風險組合已消除或補丁已覆蓋，繼承關係已核查 | `nginx -T` 的減敏摘要、稽核記錄 | | TLS/mTLS | 可信任證書通過；無效或缺失證書被拒絕；會話恢復不繞過認證 | 負向/正向授權測試，受控 TLS 測試結果 | | HTTP/3 請求體 | 啟用路徑經修復；上游請求體與限制行為正確 | HTTP/3、代理上傳、體積限制回歸測試 | | SSI/AIO | 功能符合要求，Worker 無異常中止 | 業務回歸、崩潰與錯誤率監控 | | 維運監控 | 無明顯異常 5xx、SIGSEGV、進程反覆退出 | 變更前後服務指標及日誌 | | 復原策略 | 若必須回滾，首先限制暴露並保留安全邊界 | 變更單、應急切流與隔離計劃 | | 後續生命週期 | 確定安全公告訂閱、容器更新頻率、分支遷移計劃 | 升級台帳、責任人與下次審核日期 | ### 8.1 日誌與運行狀態應重點觀察什麼 對已暴露較長時間的伺服器，排查異常 `worker process exited on signal`、`SIGSEGV`、請求失敗尖峰、異常來源存取聚集、非預期 TLS Session 恢復/認證成功以及異常的後端請求體行為。這些指標只能作為調查線索，不是直接證明某個 CVE 被利用的充分證據；缺少相關日誌也不能證明沒有受到攻擊。 ### 8.2 建議的最終風險結論措辭 生產環境的驗收報告宜使用如下精確表述： > 已識別 NGINX 對外服務入口及軟體包來源。全部適用實例已升級到上游正式安全版本，或完成發行版廠商確認的回補；舊 Worker 與舊容器均已替換。已經審計 alias/rewrite/map、AIO/SSI、HTTP/3 請求體和 TLS Session Ticket/mTLS 相關配置，並回歸功能、認證和請求完整性測試。對尚未完成升級的實例另行登記暴露面、補償措施、責任人和完成期限。 如果 Debian 12 或其他發行版的修補程式仍不完整，不宜將整張驗收表判為「已完成」；應明確記錄未解決的 CVE、是否存在對應觸發配置、隔離狀態和最終升級路線。 *** ## 附錄：引用來源與鏈接 說明：正文中的 `[Sx]` 編號統一對應本節。以下優先選擇上游專案安全公告、代碼提交、供應商發行版公告及國家安全機構資訊。引用中的漏洞嚴重性依各發布機構原口徑描述；資料核驗日期為 2026 年 10 月 27 日。 ### S1 — NGINX Open Source 官方安全公告 - 包含五項 10 月 CVE 的上游受影響版本、修復分支及官方自有嚴重性等級，也涵蓋 2026 年歷史漏洞。 ### S2 — NGINX 官方版本發布紀錄 - - 確認 2026-10-14 的 1.30.6 / 1.31.7、2026-10-21 的 1.31.8，以及 5—9 月關鍵安全修復節點。 ### S3 — 新加坡網路安全局：F5 NGINX 三項 Critical 漏洞 - 說明 CVE-2026-15176、CVE-2026-93479、CVE-2026-97205 的 CVSS v4.0 9.2 評分、必要設定條件及臨時緩解建議。 ### S4 — NHS England：F5 NGINX 高風險公告 - 說明記憶體安全問題的 DoS / 潛在 RCE 影響，以及 ASLR 關閉或被繞過等約束。 ### S5 — 官方原始碼提交：CVE-2026-15176 - 對應 `ngx_http_map_uri_to_path()` 中 `alias` 與 `r->uri_changed` 的狀態檢定。 ### S6 — 官方原始碼提交：CVE-2026-93479 - 對應 HTTP/Stream 腳本長度與保留緩衝區分配邏輯。 ### S7 — 官方原始碼提交：CVE-2026-97205 - 對應 `r->main->blocked` 計數閾值 `NGX_HTTP_MAX_BLOCKED 250` 與非同步路徑回退。 ### S8 — 官方原始碼提交：CVE-2026-95101 - 對應 HTTP/3 未知幀剩餘長度與 DATA 請求體長度的狀態分離。 ### S9 — 官方原始碼提交：CVE-2026-97629 - 對應同步 TLS Session Ticket 輪換期間全部密鑰插槽。 ### S10 — F5：CVE-2026-15176 廠商公告 - 列舉 `alias`、`rewrite`、`$request_filename` 與存取日誌等觸發要素。 ### S11 — F5：CVE-2026-93479 廠商公告 - 列舉 map regex 擷取、根路徑和日誌變數求值條件。 ### S12 — NGINX 官方 TLS/SSL 模組文檔 - 說明 `ssl_session_cache`、`ssl_session_tickets`、`ssl_session_ticket_key` 和客戶端憑證認證等指令。 ### S13 — 安全諮詢: Ubuntu USN-8955-1 (2026-10-26) - 提供 Ubuntu 22.04 / 24.04 / 26.04 / 26.10 的完整軟體包修復版本及發行版適用範圍。 ### S14 — 安全諮詢: Debian DSA-6575-1 (2026-10-21) - 確認 Debian 13 / trixie 的安全修復套件 `1.26.3-3+deb13u10`，並記錄 CVE-2026-93479 的回補關聯。 ### S15 — 漏洞追踪: Debian Security Tracker: CVE-2026-15176 - 用於核驗 Debian 12 / bookworm 與 Debian 13 / trixie 的發行版修復狀態。此狀態可能會隨未來安全性更新而改變。 ### S16 — 漏洞追踪: Debian Security Tracker: CVE-2026-95101 - 補充確認 HTTP/3 漏洞在不同 Debian 分支上的安全狀態。 ### S17 — 安全諮詢: Red Hat: CVE-2026-93479 - 補充理解 10 月回歸漏洞與 7 月 CVE-2026-42533 的修復關聯。 ### S18 — NGINX 官方反向代理模組文檔 - - 查詢 `proxy_request_buffering`、`client_max_body_size`、`alias`、`aio` 等配置的語意和預設值。 ### S19 — NGINX Plus 官方 Release Notes - 列出 Plus CR/LTS 分支、版本、補丁及升級相容提醒。 ### S20 — NGINX JavaScript / njs 官方安全公告 - - 包含 2026 年 10 月 njs 1.0.2 和相關 XML 驗證、記憶體耗盡問題。 ### S21 — Kubernetes：社群 ingress-nginx 正式退休說明 - - 說明專案於 2026 年 3 月停止新版本及安全修復，建議遷移受維護控制器或 Gateway API。 ### S22 — NGINX 官方服務控制與線上二進位升級說明 - 區分配置 reload、重新啟動及線上執行檔升級方式，用於程序切換驗收。 ### S23 — 政府安全通告：2026 年 5 月 NGINX rewrite 漏洞 - - 提供 CVE-2026-42945 的歷史風險背景與安全更新建議；野外利用相關判斷應以當時機構公告及進一步事件證據為準。 ### S24 — F5：CVE-2026-95101 與 CVE-2026-97629 廠商公告 - - 分別涵蓋 HTTP/3 請求體注入與自動 TLS Ticket 金鑰輪換風險。 ### S25 — F5：CVE-2026-97205 廠商公告 - 描述 SSI/AIO 觸發條件及潛在的記憶體破壞風險。 [NGINX 安全性更新：設定排查、升級與驗收要點](https://keendigit.com/zh-hant/news/nginx-security-update) ## 安全維護咨詢 不確定證書信任變化如何影響你的系統？我們可以協助排查受影響的客戶端，並制定安全更新計劃。 [咨詢安全更新]() [原始頁面]() · [內容索引]() KeenDigit LLC · 懷俄明州登記編號: 2026-002106155 [前往懷俄明州州務卿官網核驗]() © 2026 KeenDigit LLC · 美國懷俄明州 Sheridan · 保留所有權利。