Apache HTTP/2 CVE-2026-23918：兩個 frame 就能把全世界一半的 Web Server 打掛——而且 RCE 路徑是實作出來的，不是理論

2026 年 5 月 27 日，Apache 公布了 CVE-2026-23918 的修補檔——這是 mod_http2 裡的一個關鍵等級（CVSS 8.8）double-free，影響 Apache HTTP Server 2.4.66，已於 2.4.67 修正。漏洞可在未經身分驗證、單條 TCP 連線、兩個 HTTP/2 frame 的條件下被觸發，目標是任何「預設啟用 HTTP/2」的設定——也就是多數對外暴露的 Apache 安裝。DoS 路徑微不足道。RCE 路徑也不是理論：研究員 Bartlomiej Dmitruk（Striga.ai）與 Stanislaw Strzalkowski（ISEC.pl）展示了一個用 Apache scoreboard 記憶體當固定錨點的穩定 RCE 鏈。如果你在運維任何對外的 Apache，這就是本週、大概也是本季最該優先處理的補丁。

一、白話三句話講壞在哪

當客戶端送出一個 HTTP/2 HEADERS frame，緊接著對同一條 stream 送一個 error code 非零的 RST_STREAM frame——而 multiplexer 還沒登錄這條 stream 之前——兩個 nghttp2 callback 會依序觸發：on_frame_recv_cb 處理 RST、再 on_stream_close_cb 處理 close。兩個都會呼叫 h2_mplx_c1_client_rst，後者呼叫 m_stream_cleanup，把同一個 h2_stream 指標兩次推進 spurge 清理陣列。稍後 c1_purge_streams 迭代這個陣列，對每一項呼叫 h2_stream_destroy，於是同一塊記憶體被 free 兩次。

二、為什麼 RCE 路徑可行、不只是理論

對 double-free 走 RCE 的標準反駁是：「ASLR 讓被 free 的指標位址不可預測」。Apache 在一個微妙的點上把這道防線打掉了。Apache 的 scoreboard——讓 mod_status 與 worker process 追蹤每個 worker 狀態的共享記憶體區段——在 server 啟動時就配在固定虛擬位址，而且這個位址在 ASLR 啟用時，仍與父程序同壽。攻擊者可以把一個偽造的 h2_stream 結構放進 scoreboard 記憶體，把它的 pool cleanup 函式指到 system()、用 mmap 重用機制 prime 那塊被 free 的記憶體、再用 scoreboard 同時當作偽結構與指令字串的穩定容器。結果是：一個原裝、預設加固的 Apache 上，可以做到決定性的 RCE。

這是 2018 年 nginx mp4 模組那波之後，我們看過最乾淨的「ASLR 在有固定共享記憶體區段時救不了你」教科書範例。預期公開 exploit 在幾天內就會釋出，私下流通的可能已經有了。

三、週一上班前你該跑完的 60 分鐘加固

0–10 分鐘：補上或關掉 HTTP/2。升級到 Apache 2.4.67。如果接下來幾小時內補不了，在 vhost 層級關掉 HTTP/2（Protocols http/1.1）並 reload。你會失去 HTTP/2 的效能，但你保住了你的 server。當天稍晚再補。

10–25 分鐘：掃描與盤點。找出你周邊每一個 Apache 實例。如果自架：對你的對外網段跑 nmap -p 443 --script http2-info。如果你站點在 CDN 後面，CDN 通常會在邊緣終止 HTTP/2——確認原站 Apache 不是直接對外。風險最高的是「你忘了存在」的那些：staging server、舊版後台、某人 2019 年架的廠商 portal。

25–40 分鐘：開啟 mod_security 並套用 OWASP CRS 的 HTTP/2 規則。OWASP Core Rule Set 4.7 版本內建了會偵測「HEADERS 緊接 RST」這個特定序列的啟發式規則。它不是完整緩解，但會把刺探成本拉得很高，並給你可以告警的 log。

40–55 分鐘：對崩潰特徵建告警。DoS 觸發在 Apache error log 留下不可錯認的痕跡——帶 HTTP/2 stream ID 的反覆 worker segfault。加一條高優先級告警。一旦看見它，當作有人正在實際攻擊處理，把任何可能曾在 process 記憶體裡的祕密都輪替掉。

55–60 分鐘：寫事後紀錄。就算你補得乾淨，也寫一段「我們跑 2.4.66、暴露窗口、我們做了什麼」給資安關係人。這是日後被追問時最便宜的保險。

四、這對 Apache 與 NGINX 之爭的影響

一個月內三個 CVE——NGINX Rift（5/17）、這個 Apache HTTP/2（5/27）、Gitea 容器映像繞過（5/27）——都打在被廣泛部署的自架基礎設施，根因都很深：舊的程式碼路徑、固定的記憶體區、第二條存取路徑漏掉授權檢查。結論不是「換 web server」。結論是 2026 年任何自架邊緣基礎設施，都需要一個專人在 24 小時內讀揭露 feed、做出反應——不管他跑的是 NGINX、Apache、Caddy 還是 Traefik。這個週末把 Apache 2.4.67 上 production 的團隊，跟兩週前把 NGINX 1.30.1 上 production 的團隊，是同一群人：他們是「本來就有人在做這件事」的團隊。其他人正在再一次發現：「補丁有空再補」不是真正的資安姿勢。

五、Laravel 與 PHP 團隊更深一層的功課

如果你的 Laravel 跑在 Apache 上，這個補丁是你的事。如果你的 Laravel 跑在 NGINX 後面，下列任一條成立時，這個補丁仍然是你的事：你的 staging server 跑 Apache、你的 CI runner 用 Apache 開預覽、某個內部後台工具藏在 Apache 反向代理後面、某個舊 WordPress 站跟你共用邊緣。把「盤點」當作真正的工作。補丁 30 秒，盤點 1 小時。2026 年多數事故事後追溯，都會回到「現役團隊沒人記得這台還在跑」的 Apache（或 NGINX、或 IIS）上。

我的觀點

CVE-2026-23918 是今年最乾淨的示範，告訴你現代攻擊面不是「你的程式碼」，是「你的資產盤點」。漏洞本身是 h2_mplx.c 裡五行的清理路徑錯誤。它之所以致命，是因為多數運維者並沒有一份「現在什麼跑在哪」的最新地圖。最有性價比的防禦，不是去模糊測試 mod_http2，是那份很無聊的紀律——維護最新資產清單、每項資產有負責人、Critical 補丁 24 小時內處理的 SLA。每一次這種 CVE 落地，同一批公司清爽地中和，同一批公司鼻青臉腫。這不是運氣問題，是「揭露落地之前，這份清單存不存在」的問題。在週三平靜的午後把這份清單建好，不要在週四火燒屁股的時候建。