資安研究機構 DepthFirst AI 近日揭露多個影響 NGINX Plus 與 NGINX Open Source 的安全漏洞。其中一項 CVSS v4 評分高達 9.2 分的堆積緩衝區溢位漏洞尤為關鍵，因為它在 NGINX 程式碼中潛伏長達 18 年，直到近期才被發現。
漏洞概述
該漏洞被命名為「NGINX Rift」，追蹤編號為 CVE-2026-42945，存在於 NGINX 的 ngx_http_rewrite_module 模組。F5 已於本週三發布資安公告確認此事，影響範圍涵蓋 NGINX 0.6.27 至 1.30.0 的所有版本。
值得注意的是，這項漏洞並非透過人工稽核發現，而是由 DepthFirst AI 的自主掃描系統在僅歷時六小時的程式碼分析作業中挖掘出來；同場也發現另外三個與記憶體損毀相關的漏洞。
NGINX 是全球使用最廣泛的網頁伺服器與反向代理平台之一。據統計，它支撐著全球前段排名網站中約三分之一的流量，並廣泛應用於雲端服務商、SaaS 企業、銀行、媒體平台、電商網站，以及 Kubernetes 叢集環境。
技術根因：兩次計算出現落差
CVE-2026-42945 的根源，在於 NGINX 內部腳本引擎在處理重寫指令時，對狀態的管理不一致。NGINX 執行重寫採兩階段流程：第一階段先計算需要配置的記憶體大小，第二階段才實際複製資料。
問題出在名為 is_args 的旗標上：當 rewrite 指令包含問號「?」時，該旗標在第一階段結束後仍維持啟用。結果是系統在計算緩衝區大小時，使用未跳脫的 URI 長度；但在實際寫入時，寫入的卻是長度更長的已跳脫資料（例如「+」與「&」），因而導致堆積緩衝區溢位。
DepthFirst 指出，當 NGINX 同時使用 rewrite 與 set 指令時，就可能觸發此條件；而這類配置在 API 閘道與反向代理部署中相當常見。
攻擊門檻低，且具可塑性
F5 公告指出，只要攻擊者能透過 HTTP 連線到達一台存在漏洞的 NGINX 伺服器，即可藉由精心構造的請求觸發 worker 行程的堆積溢位；過程中沒有登入步驟、不需要事先取得存取權限，也不依賴任何既有工作階段。
更危險的是，溢位寫入的位元組來自攻擊者提供的 URI，代表記憶體損毀內容可被攻擊者主動塑形，而非隨機雜訊，因而大幅提高穩定利用的可能性。
DepthFirst 研究人員更示範如何透過惡意 HTTP 請求達成未認證的遠端程式碼執行（RCE）：先破壞相鄰 NGINX 記憶體池結構、覆寫清理處理程序指標，再利用 POST 請求本體將偽造結構噴射至記憶體，最終迫使 NGINX 在記憶體池清理期間呼叫 system()。
不過研究人員也補充，測試環境中的完整 RCE 是在關閉位址空間配置隨機化（ASLR）的條件下達成。ASLR 是一種防禦記憶體攻擊的機制，多數作業系統預設啟用，但部分追求效能的嵌入式系統或虛擬機器環境可能會將其關閉。
NGINX 的多行程架構也意外成為攻擊助力：worker 行程的記憶體配置繼承自主行程，使得每次重啟後的記憶體佈局幾乎完全相同。這讓攻擊者能在 worker 崩潰後反覆嘗試，而不必擔心記憶體配置改變。研究人員甚至指出，理論上可利用此特性逐位元組覆寫指標，以洩漏 ASLR 資訊。
其他同場修補的漏洞
除 CVE-2026-42945 外，F5 此次也同步修補另外三個影響 NGINX Plus 與 NGINX Open Source 的漏洞：
- CVE-2026-42946（CVSS v4 8.3）：ngx_http_scgi_module 與 ngx_http_uwsgi_module 模組存在過度記憶體配置問題。具備中間人攻擊（AitM，Adversary-in-the-Middle）能力的遠端未認證攻擊者可藉此讀取 NGINX worker 行程記憶體，或使其重新啟動。
- CVE-2026-40701（CVSS v4 6.3）：ngx_http_ssl_module 模組存在釋放後使用漏洞。在啟用 ssl_verify_client 與 ssl_ocsp 指令的特定配置下，攻擊者可在有限範圍內修改資料，或使 worker 行程重啟。
- CVE-2026-42934（CVSS v4 6.3）：ngx_http_charset_module 模組存在越界讀取漏洞。在同時使用 charset、source_charset、charset_map，並於 proxy_pass 配置中停用緩衝的情境下，可能造成記憶體內容洩漏或 worker 行程重啟。
修補版本與防護建議
F5 已在 CVE-2026-42945 於 2026 年 4 月 21 日完成負責任揭露後，發布對應修補版本。建議管理者依以下優先順序採取行動：
- 將 NGINX Open Source 升級至 1.30.1 或 1.31.0 以上版本
- NGINX Plus 用戶升級至 R32 P6 或 R36 P4 以上版本
- 若無法立即修補，應將 rewrite 指令中的所有未命名捕獲（unnamed capture，如 $1、$2）改為具名捕獲，作為暫時緩解措施
- 確認部署環境的 ASLR 防護機制處於啟用狀態
- 同步更新 NGINX Instance Manager、NGINX App Protect WAF、NGINX Gateway Fabric 及 NGINX Ingress Controller 等相關產品至各自的修補版本
本文轉載自 TheHackerNews、BleepingComputer。