【緊急】最有力氣的漏洞!人人都能打崩網站,88萬台服務器裸奔,CVSS 9.8拒絕服務漏洞 | CVE-2026-49975 | HTTP2 Bomb

The Only Bamboo
243粉絲
#計算機 #cybersecurity #https #nginx #http #webserver #科技 #technology #計算機科學 #hacker #黑客 #網絡安全 #信息安全 #ddos #cve #exploit #manosaba #橘雪莉
目前測試很多網站都是能打的
當然大家注意不要濫用
---------------------------------------------------------------------------------------
HTTP/2 Bomb(CVE-2026-49975)| CVSS 9.8 | 千倍內存放大 DoS
“家用寬帶 100Mbps 就能搞發動的超值DoS”
漏洞由 Calif 用 OpenAI Codex 發現,兩個十年老技術組合。
影響的框架:nginx、Apache、IIS、Envoy、Cloudflare Pingora
修復方案:
- nginx:升級 1.29.8+
- Apache:升級 mod_http2 v2.0.41+
- IIS/Envoy/Pingora:暫無補丁,建議禁用 HTTP/2 或部署前置代理
PoC 復現筆記:https://github.com/Unclecheng-li/poc-lab
網安日報:https://unclecheng-li.github.io/cybersecurity-daily/
AI 生成·可能包含錯誤
視頻概述
AI 生成這段影片詳細分析了代號為「HTTP2 BOMB」的嚴重漏洞(CVE-2026-49975),該漏洞允許攻擊者利用極小流量對企業級服務器發起毀滅性的DoS攻擊,導致內存迅速耗盡而癱瘓。
注意看眼前這樣攻擊會徹底顛覆你對DOS攻擊的認知
只需要用一臺普通的家用電腦搭配百兆寬帶
然後只需要輸入一行攻擊命令
就能在短短的十幾秒連續擊潰64GB甚至32GB的大內存企業級服務器
我們在畫面裏能看到四臺服務器
左上角的Apache
右上角的Envoy
左下角的Microsoft IIS
和右下角的Nginx服務器
那麼每個都是攻擊者發送幾KB的極小流量
然後憑藉着最高接近5700倍的流量放大
迫使服務器瘋狂分配內存
而且攻擊者還通過流控會讓這些被佔用的內存徹底鎖死無法釋放
那麼Envoy Nginx IIS Apache四大主流服務器全部中招
32GB內存服務器10秒鐘就直接癱瘓
連64GB的Windows服務器也撐不過45秒
而且這套攻擊能直接繞過WAF
繞過請求數量
請求頭大小限制等絕大多數的傳統防禦
流量特徵和正常訪問也毫無區別
極難被檢測攔截
而目前全球已經有88萬臺服務器暴露在風險中了
國內的大量高校和企業佔領也實測中招
那麼這就是CVE-202649975代號HTTP2 BOMB
在滿分10分的CVSS下得到9.8的評分
嚴重級別
攻擊者只需要發送一個HTTP2請求
就能夠發起一次千倍以上放大的DOS攻擊
HTTP2是現代web的基礎協議
相比起第一版
它引入了多路附用和頭部壓縮等特性
其中HPAC壓縮算法是用來減少HTTP頭部的傳輸大小的關鍵技術
在正常情況下
客戶端和服務器會維護一個動態表
用來存儲已經發送的頭部織端
後續的通信中可以用一字節的鎖影來引用之前存儲的頭部
在服務器解碼的時候會把鎖影展開成完整的頭部內容
這樣的話可以減少網絡傳輸量
提高效率
但是問題來了
攻擊者可以先向動態表插入一個比較大的頭部
比如說cookie
然後在單個請求中發送幾千個指向這個表象的一個字節的鎖影的引用
服務器在解碼的時候就要給每個鎖影引用
分配完整的頭部內存
發送幾千個一字節引用
網絡流量只有幾kb
但是卻能夠讓服務器分配幾兆的內存
那麼實測放大比率高達1357比1
而且這個是最低最低的
至少會放到這麼多倍
而且這還不是最可怕的
http2還有流控機制
就是允許接收方通過發送window update
來控制發送方的數據傳輸窗口的大小
攻擊者在建立連接的時候
把初始窗口大小設置爲0
那麼服務器在接收到請求並分配大量內存之後
就永遠無法向客戶端發送響應數據了
這樣的話已經分配的內存就永遠不會被釋放了
牢牢的鎖定在那裏
所以攻擊令就是這樣
先用hpeg炸彈觸發服務器分配大量內存
然後再用窗口停止
讓這些內存永遠無法釋放
這樣的話攻擊者只需要用極小的網絡流量
就能觸發服務器的大量的內存分配
並且讓內存永遠無法回收
持續攻擊會迅速的耗盡服務器的內存
導致服務器徹底癱瘓
而且更恐怖的是
這種攻擊能照顧大多數的傳統防禦
頭部數量限制 繞過
因爲解碼後
服務器會認爲請求中只有一個合併後的cookie頭部
頭部大小限制 繞過
因爲解碼後
單個頭部值的大小在正常範圍內
放大是來源於重複的引用
請求抑制防禦 繞過
因爲攻擊的請求體積和頻率都非常低
和正常的流量是難以區分
WARF無效
基於請求特徵的檢測 無效
那麼影響範圍有多大呢
受影響的服務器包括Nginx
Apache Microsoft IIS
Envoy 甚至Cloudflare PinAura
根據Sodan掃描
全球大約有88萬臺服務器暴露在風險中
國內實測200多所高效網站中
有58所確認存在漏洞
然後再來看看利用代碼
Python3 exploit指向一個腳本
然後指定它的攻擊的服務器端口
還有攻擊的持續時間
就這一行指定目標
保持30秒
服務器內存就被鎖死了
當然還有一點好消息
就是部分廠商已經發布了修復
比如Nginx升級到1.2 9.8版本
新增了max header的指令
默認限制1000個請求頭
阿帕奇升級到mod http2 2.0.41版本
將cookie頭部進入limit request fail的限制
但壞消息就是
目前就是截止到6月4日
我寫稿完畢的時候
Microsoft IIS Envoy和Cloudflare PinAura
都還沒有官方補定
那麼對於這些服務器
建議暫時進入http2
或者在前端部署的時候
嚴格限制頭部數量的代理
如果不能升級的話
可以通過容器或者cgroups
限制worker進程的內存
確保單個被攻擊的進程
能夠及時的被殺死
然後重啓
然後就是點終點的
這個漏洞是由
Calif安全公司研究員
通過codex發現的
沒錯還是AI
那麼AI通過分析代碼庫
把這兩個已知有10年的技術
就是HPAC炸彈和流控停滯
這兩個組合成了新的攻擊路徑
而且修復提交一旦公開
AI就會被用於快速的生成利用的代碼
目前來看AI對紅隊的幫助
還是遠遠大於藍隊的
那麼AI怎麼用於防守
怎麼給防守提效
反而成了比較困難的議題
好的
那麼以上就是本期視頻的全部內容了
如果覺得有用的話求個三年
我們下期視頻再見吧
