資訊安全

Nginx 18 年的老 bug 被掛上能用的 exploit——而你的 rewrite 規則可能就是引爆點

2026.05.19 · 39 次瀏覽
Nginx 18 年的老 bug 被掛上能用的 exploit——而你的 rewrite 規則可能就是引爆點

CVE-2026-42945 是潛伏在 ngx_http_rewrite_module 裡的 heap buffer overflow,從 0.6.27 一路到 1.30.0;5/13 PoC 公開、5/16 已偵測到野外攻擊。這篇教你升什麼、grep 什麼、Laravel 在後面要怎麼加固。

2026 年 5 月 13 日,Nginx 公告 CVE-2026-42945。兩件事讓它成為本週的安全頭條。第一,這個 bug 從 2008 年就在生產環境,藏在多數維運把它當水電的那塊程式碼裡——rewrite module。第二,到 5 月 16 日,VulnCheck 的 honeypot 網路已經記錄到野外攻擊,PoC 也已經在 GitHub 上躺了三天。CVSS 9.2。


洞在 ngx_http_rewrite_module。當一條 rewrite 指令用了未命名的 PCRE capture(也就是經典的 $1$2),替換字串裡含問號,而那個區塊後面又接了另一條 rewrite、if 或 set 指令在同一個 scope,Nginx worker 程序就能被誘導觸發 heap buffer overflow。精心構造的 HTTP request 可以穩定打掛 worker——光這個就是 DoS。在 ASLR 關閉、或攻擊者用 heap grooming 串到記憶體洩漏 side-channel 的環境上,這就變成 RCE。


一、修補方式與「先擋一下」的低成本作法


修正在 nginx-1.30.1 stable 與 nginx-1.31.0 mainline。如果今晚還沒辦法部署新版本,可以先做一件 grep 級的工作:把所有 nginx.conf 與 include 進來的 server block 翻一輪,找出「未命名 PCRE capture」搭配「替換字串含問號」的 rewrite 規則,把它改成具名 capture 或讓 redirect 直接終止該區塊。一位資深 SRE 一個小時就能掃完一個機房:


grep -rE 'rewrite\s+[^;]+\$[0-9]+[^;]*\?' /etc/nginx/

二、誰實際暴露在風險中


Nginx 從 0.6.27(2008)一路到 1.30.0 都中。基本上就是任何曾經被部署過的 Nginx。受影響的設定組合比較窄——你需要那組「未命名 capture + 含 ? 的替換 + 同 scope 跟著另一條指令」的特定形狀——但這 72 小時陸續釋出的 WAF 遙測顯示,這個組合在現實環境其實很常見,被攻擊的不是實驗目標,是真正在跑生意的負載。任何 Laravel 跑在 Nginx 後、又帶傳統 URL rewrite 的環境,都該當作「本週要修,不是這一季要修」。


三、Laravel 的暴露面


Laravel 的 public/.htaccess 與標準 Nginx 設定,那條乾淨的 front-controller rewrite 並不會打到這個 pattern。但很多團隊在主規則旁邊外掛了一堆 legacy redirect——遷移過來的 WordPress、帶 query-string 自訂改寫的行銷活動頁、按 prefix 分租的多租戶設定——這些位置才是脆弱形狀最常出現的地方。盤點要走遍每一個 serverlocation 區塊,不是只看 Laravel 那條。


四、Worker 程序的縱深防禦


修補的同時做四件事。一、確認 ASLR 是開的(Linux 預設已經開很多年,但容器與精簡 image 偶爾會關掉)。二、設好 worker 的資源上限,讓單一 worker 崩潰時不會帶倒整台主機。三、在前面掛上 WAF 規則,擋住觸發這個 PCRE 形狀的請求——Cloudflare 與 AWS WAF 的 managed rules 已經在 5/14 推出簽章。四、把 worker process exited on signal 11 列入監控,第一次出現就告警。這個 exploit 不安靜,你只要在聽。


五、更大的教訓


這個 bug 18 歲。其實一點都不稀奇——去年的 CUPS 一連串、幾個月前 OpenSSH 那個 regression,形狀都一樣。我們基礎設施裡那些沒人想看的程式路徑——rewrite module、log filter、那個沒人負責的 cron——一直在生產最糟的漏洞。處理得好的團隊,不是更怕資安,而是行事曆上本來就有一條「每一季 Nginx 設定盤點」。原因很簡單:自己發現 bug 的成本,永遠低於 VulnCheck 告訴你的成本。


我的觀點


2026 年跑一個公開的 web stack,最難的不是那些新東西。不是 Kubernetes、不是 Cloudflare、不是你放進生產線的 AI agent。最難的是那個 18 歲、自 2008 年起沒人再讀過的程式路徑,它是公網與你的應用程式之間唯一的那一道牆。CVE-2026-42945 提醒所有人一件事:「我們跑這個跑很多年都沒事」不是資安姿態,那叫沒掃過的閣樓。今晚就修。


資料來源