HTTP/2 Bomb 漏洞怎麼處理？CVE-2026-49975 的影響範圍與緩解思路

HTTP/2 Bomb 是近期公開的一個 HTTP/2 拒絕服務風險。它和 CVE-2026-49975 相關，核心問題是攻擊者可以用很小的請求，讓服務端分配並長時間占用大量記憶體，最終導致服務變慢、進入 swap，甚至不可用。

這個問題最容易被誤解成「又一個普通 DDoS」。但它的危險點不在於流量大，而在於記憶體放大明顯：客戶端發出的資料很少，服務端卻可能在處理 HTTP/2 頭部壓縮和流控狀態時承擔成倍資源消耗。

對維運和安全團隊來說，當前最重要的不是復現攻擊，而是先確認自己哪裡終止了 HTTP/2，再按元件升級或臨時關閉 HTTP/2。

這個漏洞危險在哪裡

HTTP/2 Bomb 把兩類老問題組合在了一起。

第一類是 HPACK 相關的壓縮放大。HTTP/2 使用 HPACK 壓縮頭部，客戶端可以用很短的引用讓服務端還原和分配頭部結構。如果實作沒有對頭欄位數量、Cookie 分片或內部簿記開銷做足夠限制，服務端就可能為很小的輸入分配大量記憶體。

第二類是類似 Slowloris 的「拖住不放」。攻擊端可以利用 HTTP/2 的流控機制，讓服務端回應無法正常完成，從而把前面分配出來的記憶體長時間釘在進程裡。

單獨看，這兩類問題都不新。真正麻煩的是它們疊加以後，攻擊不需要很高頻寬，也不一定需要海量連線，就可能把後端記憶體壓到危險狀態。

哪些元件需要重點關注

公開披露中提到的受影響或需要關注的 HTTP/2 服務端實作包括：

nginx
Apache httpd
Microsoft IIS
Envoy
Cloudflare Pingora

NVD 目前對 CVE-2026-49975 的描述聚焦在 Apache HTTP Server mod_http2，影響範圍為 Apache HTTP Server 2.4.17 到 2.4.67。Red Hat 公告也把相關問題歸到 HTTP/2 HPACK 拒絕服務，並指出 httpd、nginx、Envoy 等元件需要分別處理。

這裡要注意兩個細節。

第一，不是所有「後端應用服務」都直接暴露這個風險。真正需要先排查的是 HTTP/2 終止點：公網負載平衡、反向代理、Ingress、閘道、CDN 回源層、API Gateway、服務網格入口等。

第二，不同廠商、發行版和產品的 CVE 歸屬不完全一致。不要只看一個 CVE 編號就判斷所有元件都已覆蓋；更穩妥的做法是按實際 HTTP/2 元件查看對應廠商公告。

怎麼快速自查

可以先按這條順序排查：

你的公網入口是否啟用了 HTTP/2；
HTTP/2 在哪裡終止，是 CDN、WAF、負載平衡、Nginx、Apache、Envoy、IIS，還是服務網格；
終止 HTTP/2 的元件版本是否在廠商已修復範圍內；
是否有上游代理能限制請求頭欄位數量、Cookie 分片、連線生命週期和單 worker 記憶體；
是否存在繞過 CDN/WAF 直連源站的入口。

很多網站看似有 CDN，但源站 IP、備用網域、測試網域、管理入口或灰度入口仍然可能直接暴露 HTTP/2。真正要檢查的是「所有能接 HTTP/2 的邊界」，不只是主站網域。

修復和緩解建議

優先級最高的是升級。

如果使用 nginx，公開披露中提到 1.29.8+ 引入了相關限制。無法升級時，可以考慮臨時關閉 HTTP/2。

如果使用 Apache httpd，需要關注 mod_http2 修復版本。公開資料提到 mod_http2 v2.0.41 進行了修復；Red Hat 給出的臨時緩解方式是讓相關虛擬主機只使用 HTTP/1.1：

1

Protocols http/1.1

如果使用 nginx 並需要臨時緩解，可以按廠商或發行版建議關閉 HTTP/2，例如：

1

http2 off;

如果使用 Envoy、IIS、Pingora 或託管閘道，要跟隨對應廠商公告。不要直接套用 Nginx 或 Apache 的配置思路，因為具體限制點和修復方式可能不同。

對於暫時無法升級的系統，可以考慮這些防守措施：

在邊界層限制單請求頭欄位數量，包括拆分後的 cookie 欄位；
限制異常長生命週期的 HTTP/2 stream；
對 HTTP/2 入口設定連線數、並發 stream、請求速率和記憶體上限；
對 worker 或容器設定合理記憶體上限，避免一個進程拖垮整機；
讓源站只接受可信代理訪問，避免繞過 WAF/CDN；
監控 HTTP/2 連線數、活躍 stream、記憶體飆升、swap 使用和 5xx。

這些措施不能替代補丁，但能減少暴露窗口。

哪些場景風險更高

風險更高的通常是這些環境：

公網直接暴露 HTTP/2 的 Nginx / Apache / Envoy / IIS；
API 閘道或 Ingress 接入層開啟 HTTP/2；
源站可以被繞過 CDN 直接訪問；
單機記憶體較小，但承載多個站點或多個業務；
沒有 worker / container 記憶體限制；
缺少異常連線、stream 和記憶體監控；
業務對可用性敏感，但沒有快速回滾 HTTP/1.1 的預案。

如果你的服務只在內網使用，也不能完全忽略。內網攻擊、誤用測試腳本、供應鏈元件暴露、服務網格入口配置錯誤，都可能讓風險從公網問題變成橫向移動後的可用性問題。

不要只盯 CVSS 分數

這類漏洞的分數容易讓人困惑。有的資料強調 CVSS 9.8，NVD 頁面目前又顯示 CISA-ADP 給出的 CVSS 3.1 為 7.5 High，且 NVD 自身評分仍在補充中。

對實際防守來說，分數不是第一判斷依據。更實用的問題是：

你的 HTTP/2 入口是否受影響；
是否公網可達；
是否已經升級到廠商修復版本；
是否能快速關閉 HTTP/2；
是否有記憶體、連線和 stream 級別的保護；
是否存在繞過前置防護直連源站的路徑。

如果這些問題裡有多個答案不確定，就應該按高優先級處理。

維運側建議的處理順序

可以按下面的順序推進：

列出所有 HTTP/2 終止點；
對照廠商公告確認版本和修復狀態；
優先升級公網入口和邊界代理；
對暫時無法升級的入口臨時關閉 HTTP/2；
檢查源站是否只允許可信代理訪問；
給 worker、容器或服務進程設定記憶體邊界；
加上 HTTP/2 連線、stream、請求頭欄位數量和記憶體異常監控；
在變更窗口後驗證業務是否仍能正常訪問。

關閉 HTTP/2 可能影響效能、連線複用和部分客戶端體驗，但在補丁不可用或風險不清楚時，這是比裸奔更穩的臨時選擇。

結論

HTTP/2 Bomb 的關鍵不是「流量有多大」，而是「小請求觸發大記憶體占用，並且能把記憶體占用拖住」。這讓它對預設開啟 HTTP/2 的邊界服務更危險。

處理時不要急著復現，也不要只看某個 CVE 頁面。先找出所有 HTTP/2 終止點，再按 Nginx、Apache、Envoy、IIS、Pingora 或發行版公告逐個確認。能升級就升級，不能升級就臨時關閉 HTTP/2，並在邊界層增加頭欄位、連線、stream 和記憶體限制。

參考來源：Calif 原始披露、NVD CVE-2026-49975、HAProxy 分析、Red Hat RHSB-2026-007