CVE-2026-42945 怎麼排查？Nginx Rift 漏洞觸發條件、版本檢查與升級建議

CVE-2026-42945 是 NGINX Open Source 和 NGINX Plus 中的一個安全漏洞，外界也把它稱為 Nginx Rift。它出現在 ngx_http_rewrite_module，漏洞類型是 heap-based buffer overflow。

這類新聞很容易被寫成「潛伏 18 年」「不用密碼遠端控制」「三成伺服器中招」。這些說法有傳播性，但看補丁和 NVD 描述時，最好把風險拆開看：它確實嚴重，也確實不需要登入帳號；但並不是所有 Nginx 實例都會自動被接管，觸發需要特定 rewrite 設定和請求條件。

先看官方描述

NVD 對 CVE-2026-42945 的描述可以概括為：

影響 NGINX Plus 和 NGINX Open Source。
漏洞位於 ngx_http_rewrite_module。
當 rewrite 指令後面跟著 rewrite、if 或 set 指令，並且使用未命名的 PCRE 捕獲組，例如 $1、$2，同時替換字串裡包含問號 ? 時，可能觸發問題。
未認證攻擊者可以傳送構造請求觸發漏洞。
結果可能是 NGINX worker 程序發生 heap buffer overflow 並重啟。
如果系統關閉了 ASLR，存在程式碼執行可能。

F5 作為 CNA 給出的評分是：

CVSS v4.0：9.2，Critical。
CVSS v3.1：8.1，High。
CWE：CWE-122 Heap-based Buffer Overflow。

所以，這不是普通的「設定寫錯導致 404」問題，而是 Nginx 官方安全修復範圍內的記憶體安全漏洞。

哪些說法需要降溫

第一，「不用密碼」基本可以理解為未認證攻擊。也就是說，攻擊者不需要登入 Nginx 後台，不需要拿到 SSH，也不需要應用系統帳號。但這不等於任何公網 Nginx 都能被隨手接管。

第二，「直接遠端控制」要看條件。官方描述裡更穩妥的說法是：漏洞可導致 worker 程序重啟；在 ASLR 關閉的系統上，程式碼執行是可能結果。對啟用了 ASLR、發行版編譯加固完整、執行權限受限的環境，風險路徑會更複雜。

第三，「30% 伺服器中招」不能簡單等同於「所有 Nginx 市占率都是漏洞暴露面」。真正暴露要同時看版本、是否啟用受影響模組、是否存在特定 rewrite 設定、發行版是否已經回補補丁，以及 Nginx 執行環境的加固狀態。

更準確的判斷方式是：只要你在生產環境執行 Nginx，就應該盡快檢查；但不要只按標題裡的比例判斷自己是否中招。

受影響範圍怎麼判斷

從 nginx.org 發布資訊看，2026 年 5 月 13 日發布的 nginx-1.30.1 stable 和 nginx-1.31.0 mainline 包含多項安全修復，其中包括 ngx_http_rewrite_module 的 buffer overflow，也就是 CVE-2026-42945。

如果你使用官方 Nginx 原始碼或官方套件，可以優先關注：

NGINX Open Source stable：升級到 1.30.1 或之後版本。
NGINX Open Source mainline：升級到 1.31.0 或之後版本。
NGINX Plus：查看 F5 對應分支的修復版本。

如果你使用 Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine、容器映像、Plesk、控制面板、Ingress Controller 或雲廠商託管元件，不要只看 nginx -v 裡的上游版本號。很多發行版會把安全補丁 backport 到舊版本套件裡，版本號看起來舊，但補丁可能已經合入。

一分鐘判斷是否需要緊急處理

可以先按下面幾個問題快速分級：

這台 Nginx 是否直接暴露在公網，或者位於 API Gateway、反向代理、負載均衡、Ingress 入口層？
是否使用官方 Nginx 套件、原始碼編譯套件、第三方面板、容器映像，且還沒有確認 CVE-2026-42945 修復狀態？
設定裡是否存在複雜 rewrite 規則，尤其是連續 rewrite、if、set，以及 $1、$2 這類未命名捕獲組？
是否存在把請求路徑、查詢參數或使用者可控輸入帶入 rewrite 目標的場景？
系統加固是否較弱，例如 ASLR 被關閉、worker 權限過高、容器權限過寬？

如果前兩項命中，並且 rewrite 設定還沒有排查，建議按高優先級處理。公網入口、共享環境、Kubernetes Ingress、邊緣代理和承載登入/API 流量的 Nginx，應該優先升級或替換到確認修復的套件。

Debian / Ubuntu / RHEL / Alpine 如何確認修復

發行版使用者不要只看 nginx -v。Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine 這類系統經常把安全補丁回補到穩定分支，表面版本號可能仍然低於 nginx.org 的 1.30.1 或 1.31.0。

Debian / Ubuntu 可以優先看安全公告、套件 changelog 和可升級列表：

1
2
3
4


nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

RHEL / AlmaLinux / Rocky Linux 可以看安全更新和套件變更記錄：

1
2


yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

Alpine 可以檢查目前套件版本和安全分支更新：

1
2


apk info -v nginx
apk version -v nginx

如果套件管理器、發行版安全公告或廠商 advisory 明確寫明已修復 CVE-2026-42945，即使上游版本號看起來不新，也可以按「已回補修復」處理。反過來，如果只是版本號較高但來源不明，仍然要確認建置日期和補丁來源。

容器映像與 Ingress Controller 怎麼查

容器環境要檢查映像裡的 Nginx，而不是只看宿主機。先確認映像實際內建版本：

1
2


docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

還要看基礎映像是否更新過。如果映像基於 Debian、Ubuntu、Alpine 或發行版套件建置，判斷方式應回到對應發行版的安全公告和套件 changelog。只重啟舊映像沒有意義，映像本身需要重新建置或替換。

Kubernetes Ingress 需要同時確認三件事：

Ingress Controller 專案是否發布了針對 CVE-2026-42945 的 advisory 或修復版本。
目前叢集執行的 controller 映像 digest 是否已經更新，而不是只改了 tag。
controller 內建 Nginx 版本、建置參數和模板設定是否仍然包含高風險 rewrite 規則。

可以先看執行中的映像：

1
2


kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

如果使用雲廠商託管 Ingress 或網關，還要查對應雲服務公告。託管元件通常不是使用者自己 apt upgrade 能解決的，需要等待廠商修復或切換到已修復版本。

rewrite 設定重點排查哪些寫法

這個漏洞和 rewrite 設定有關，排查時可以先搜尋 Nginx 設定：

1
2


grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

重點關注類似模式：

1

rewrite ^/old/(.*)$ /new/$1? permanent;

這裡的 $1、$2 這類未命名捕獲組，以及替換目標中的 ?，是官方描述裡的關鍵條件之一。排查時尤其關注下面幾類寫法：

一個 rewrite 後面緊跟另一個 rewrite、if 或 set。
正則裡使用 (.*)、(.+) 這類寬泛捕獲，並在目標裡用 $1、$2。
rewrite 目標裡帶 ?，用於拼接或丟棄查詢參數。
rewrite 輸入來自公網路徑、Host、URI、參數或上游可控值。
面板、網關、Ingress 註解或模板自動生成的 rewrite 規則。

如果短時間內無法升級，可以先做臨時緩解：

減少複雜 rewrite 規則。
把未命名捕獲組改成更清晰的命名捕獲。
避免在替換字串裡拼接不必要的 ?。
對高風險入口加 WAF 或反向代理規則。
確認系統啟用了 ASLR。
降低 Nginx worker 執行權限，確認 systemd sandbox、SELinux/AppArmor 等加固狀態。

這些只是緩解，不是替代補丁。

修復優先級

建議按暴露面排序：

公網入口 Nginx。
反向代理、API Gateway、邊緣網關。
多租戶環境裡的 Nginx。
Kubernetes Ingress Controller。
Plesk、面板工具、雲市場映像等自帶 Nginx 的元件。
內網但承載關鍵業務的 Nginx。

升級後如何驗證：nginx -t、reload、worker 狀態

更新後不要只看套件管理器提示成功，還要確認設定、程序和實際二進位都已經切換。先驗證設定：

1

nginx -t

確認沒有錯誤後再平滑載入：

1

systemctl reload nginx

如果套件升級涉及二進位替換，建議確認舊 worker 已退出：

1

ps aux | grep nginx

也可以查看主程序啟動時間和二進位路徑，確認執行中的服務不是舊程序繼續駐留。必要時安排維護窗口重啟服務，避免舊 worker 或舊容器繼續處理請求。

容器和 Ingress 環境還要確認新映像已經真正滾動完成：

1
2


kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

驗證重點不是「命令執行過」，而是「線上流量已經由包含修復的 Nginx 程序承載」。

不要忽略同批次 Nginx 修復

nginx.org 在同一天發布的 1.30.1 和 1.31.0 不只修復了 CVE-2026-42945。發布資訊還提到 HTTP/2 request injection、SCGI/uWSGI buffer overread、charset module buffer overread、HTTP/3 address spoofing、OCSP resolver use-after-free 等問題。

這意味著生產環境不應該只針對單個 CVE 做臨時規則，而是應該把 Nginx 這一輪安全更新當成一次整體升級來處理。

小結

CVE-2026-42945 的關鍵點不是「所有 Nginx 都會被秒控」，而是：一個長期存在於 rewrite 模組裡的記憶體安全漏洞，在特定設定下可被未認證請求觸發，最直接後果是 worker 崩潰重啟；在 ASLR 關閉等較弱環境下，程式碼執行風險更高。

對維運來說，處理順序很簡單：

確認 Nginx 來源和版本。
查看發行版、F5、nginx.org 或雲廠商公告。
盡快升級到包含修復的版本或發行版安全套件。
排查複雜 rewrite 設定，尤其是 $1、$2 和 ? 組合。
確認 ASLR、權限隔離和服務重載狀態。

標題可以嚇人，修復要冷靜。先確認暴露面，再升級，再回頭清理高風險 rewrite 規則。