2026-07-02 05:59:59 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： HTTP/2Bomb(CVE-2026-49975)是由OpenAICodex发现的协议级拒绝服务漏洞，结合了存在十年的HPACK压缩炸弹与流控停顿技术。该漏洞实现超4000:1的内存放大率，单台家用电脑即可在10秒内打瘫32GB服务器。它影响NGINX、Apache等五大主流Web服务器及88万公网实例，因攻击流量合法而彻底绕过WAF与限流防御。根本原因在于RFC7541规范未定义条目分配器开销边界。建议立即升级至NGINX1.29.8或Apachemod_http2v2.0.41等修复版本，并严格配置头部数量限制。 综合评分： 90 文章分类： 漏洞预警,漏洞分析,WEB安全,AI安全,漏洞POC

cover_image

HTTP/2 Bomb：AI 拼出十年潜伏的协议级 DoS 核弹，880000+ 服务器一触即溃

原创

挽风挽风

挽风安全

2026年6月30日 11:57 四川

在小说阅读器读本章

去阅读

OpenAI Codex 发现 | 1 字节 = 4000 字节服务器内存 | 单台家用电脑 10 秒打瘫 32GB 服务器 | 五大 Web 服务器全部中招

一、事件概述

2026 年 6 月 2 日，加州安全公司 Calif Security 公开披露了一个名为 HTTP/2 Bomb 的远程拒绝服务漏洞。这不是一个普通的软件 bug——它是由 OpenAI Codex 大模型发现的协议级攻击，将两个存在了近十年的已知技术首次组合在一起，形成了足以瘫痪全球主流 Web 服务器的致命攻击链。

Apache 变体分配编号 CVE-2026-49975，CVSS 评分 9.8（严重级）。

核心数据：

这个漏洞的可怕之处在于：攻击者不需要僵尸网络，不需要零日漏洞利用经验，甚至不需要认证——只需要一台家用电脑和一条百兆宽带，就能在 10 秒内让一台 32GB 内存的服务器完全瘫痪。

二、漏洞背景：AI 如何发现这个潜伏了十年的漏洞

2.1 发现过程

安全研究员 Quang Luong（Calif Security）使用 OpenAI Codex 阅读了五大主流 Web 服务器的 HTTP/2 实现代码。Codex 识别出两个独立存在了近十年的攻击原语——

HPACK 压缩炸弹：Cory Benfield 在 2016 年命名（CVE-2016-6581），但当时只针对”大值填充”场景
HTTP/2 Slowloris 流控停顿：CVE-2016-8740（无界 CONTINUATION 帧）、CVE-2016-1546（工作线程饥饿）

——然后将它们串联成一个原始攻击中从未出现过的攻击链。

研究团队在事后感叹：”一旦你看到它，就会觉得它显而易见——两个部分都从 2016 年左右就公开了，但五个独立实现团队都犯了同一类错误。”

2.2 历史 CVE 谱系

2016: CVE-2016-6581&nbsp; HPACK Bomb（大值填充 → 解码大小限制，被修复）2016: CVE-2016-8740&nbsp; 无界 CONTINUATION 帧（Apache，被修复）2016: CVE-2016-1546&nbsp; 工作线程饥饿（Apache，被修复）2025: CVE-2025-53020&nbsp;Apache HTTP/2&nbsp;内存耗尽（Gal Bar Nahum，4,000x 放大）2026: CVE-2026-49975&nbsp;HTTP/2&nbsp;Bomb（空头 + Cookie 分片 + 流控停顿，5,700x 放大）

关键区别：传统 HPACK 炸弹向动态表填入大值，然后反复引用——服务器学会了限制解码后的总大小。HTTP/2 Bomb 走的是反向路径：头部几乎为空，放大来自服务器为每个条目分配的簿记开销（per-entry bookkeeping）。解码大小限制永远不会触发，因为几乎没有东西需要解码。

2.3 披露时间线

| 日期 | 事件 | | — | — | | 2026.04 | NGINX 静默发布 1.29.8，新增 max_headers 指令（默认 1000） | | 2026.05.27 | Apache 修复 mod_http2 v2.0.41，Cookie 分片计入 LimitRequestFields | | 2026.06.02 | Calif Security 公开披露，PoC 发布至 GitHub | | 2026.06.03 | 漏洞详情同步至 oss-security 邮件列表 | | 2026.06.04 | CSA 发布研究笔记，Radware/HAProxy 发布防护方案 | | 2026.06.13 | 国内安全研究员发布 200+ 高校实测报告：58 所确认存在漏洞 |

三、技术原理：1 字节 = 4000 字节，两个十年老技术如何合成核弹

3.1 攻击机制全景图

┌─────────────────────────────────────────────────────────────────────┐│ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; HTTP/2 Bomb 攻击链 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │├─────────────────────────────────────────────────────────────────────┤│ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;第一阶段：HPACK 索引引用炸弹（内存放大） &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;┌──────────────────────────────────────────────────────┐ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;│ 1. 攻击者向动态表插入一个头部（如 Cookie: AAAA...） &nbsp; &nbsp; &nbsp;│ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;│ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;↓ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;│ 2. 发送 2048 个 1 字节索引引用 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;│ &nbsp; &nbsp;网络流量：2048 字节 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;│ &nbsp; &nbsp;服务器分配：~4,000 字节 × 2048 ≈ 8 MB &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;│ &nbsp; &nbsp;放大比：~4,000:1 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;└──────────────────────────────────────────────────────┘ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;↓ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;││ &nbsp;第二阶段：流控窗口停顿（内存锁定） &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;┌──────────────────────────────────────────────────────┐ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;│ 3. 攻击者设置 INITIAL_WINDOW_SIZE = 0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;││ &nbsp;│ &nbsp; &nbsp;服务器无法完成响应 → 无法释放内存 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;│ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;↓ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;││ &nbsp;│ 4. 攻击者定时发送 1 字节 WINDOW_UPDATE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;││ &nbsp;│ &nbsp; &nbsp;重置发送超时 → 连接保持活跃 → 内存永久锁定 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;│ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;└──────────────────────────────────────────────────────┘ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;↓ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;││ &nbsp;结果：服务器内存耗尽 → OOM Killer 杀进程 → 服务瘫痪 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;││ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │└─────────────────────────────────────────────────────────────────────┘

3.2 HPACK 压缩炸弹：为什么 1 字节能换 4000 字节

HTTP/2 使用 HPACK（RFC 7541）进行头部压缩。客户端和服务器各自维护一个动态表（Dynamic Table）：

┌──────────────────────────────────────────────────┐│ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;HPACK&nbsp;动态表 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │├──────┬───────────────────────────────────────────┤│ 索引 │ 头部名称 &nbsp; &nbsp; │ 头部值 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;│├──────┼──────────────┼────────────────────────────┤│ &nbsp;62&nbsp; │&nbsp;:method&nbsp; &nbsp; &nbsp; │&nbsp;GET&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;││ &nbsp;63&nbsp; │&nbsp;:path&nbsp; &nbsp; &nbsp; &nbsp; │ / &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;64&nbsp; │ cookie &nbsp; &nbsp; &nbsp; │ a=AAAA...(4058&nbsp;字节) &nbsp; &nbsp; &nbsp; &nbsp;│ &nbsp;← 攻击者插入│ &nbsp;65&nbsp; │ user-agent &nbsp; │&nbsp;Mozilla/5.0... &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ││ &nbsp;... │ ... &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;│ ... &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; │└──────┴──────────────┴────────────────────────────┘
# 攻击者后续发送：# 0xBE 0xBE 0xBE ... (每个 0xBE 是 1 字节，指向索引 62+)# 服务器对每个 0xBE 都要重建完整的头部副本

关键代码级细节——Apache 的 Cookie 重组逻辑：

#!/usr/bin/env python3"""HTTP/2 Bomb 攻击原理模拟模拟 Apache httpd 的 Cookie 重组行为"""
# 攻击者向 HPACK 动态表插入一个 Cookie 头部# 动态表索引 62 处存储: cookie = "a=" + "A" * 4058 &nbsp;(共 4064 字节)COOKIE_VALUE =&nbsp;"a="&nbsp;+&nbsp;"A"&nbsp;*&nbsp;4058&nbsp;&nbsp;# 4064 字节
# 攻击者随后在一个请求中发送 2048 个 Cookie 分片（RFC 9113 允许）# 每个分片仅包含 1 字节的 HPACK 索引引用NUM_CRUMBS =&nbsp;2048
# 网络流量（攻击者发送）wire_bytes = NUM_CRUMBS *&nbsp;1&nbsp;&nbsp;# 2048 字节
# 服务器分配（Apache 对每个分片重建完整 Cookie 字符串）server_allocation =&nbsp;0# Apache 每个分片都重建完整合并 Cookie 字符串# 旧副本在流清理前一直存活for&nbsp;i&nbsp;in&nbsp;range(NUM_CRUMBS):&nbsp; &nbsp;&nbsp;# 每个分片强制服务器重建完整 Cookie&nbsp; &nbsp; server_allocation +=&nbsp;len(COOKIE_VALUE) &nbsp;# 4064 字节
# 放大比amplification = server_allocation / wire_bytesprint(f"网络流量:&nbsp;{wire_bytes}&nbsp;字节 ({wire_bytes/1024:.1f}&nbsp;KB)")print(f"服务器分配:&nbsp;{server_allocation}&nbsp;字节 ({server_allocation/(1024*1024):.1f}&nbsp;MB)")print(f"放大比:&nbsp;{amplification:.0f}:1")print(f"内存锁定: 攻击者设置 INITIAL_WINDOW_SIZE=0，内存永不释放")
# 输出示例:# 网络流量: 2048 字节 (2.0 KB)# 服务器分配: 8323072 字节 (7.9 MB)# 放大比: 4064:1# 内存锁定: 攻击者设置 INITIAL_WINDOW_SIZE=0，内存永不释放

3.3 Cookie 分片绕过：Apache/Envoy 的致命疏忽

这是 HTTP/2 Bomb 最精妙的部分。对于限制头部字段数量的服务器（Apache、Envoy），攻击者利用了一个协议规范漏洞：

RFC 9113 §8.2.3 明确允许将 Cookie 头部分割为多个独立字段（”分片/crumbs”）以提高 HPACK 压缩效率。

服务器需要将这些分片重组为单个 HTTP/1.1 兼容的 Cookie 头部。但 Apache 和 Envoy 没有将分片计入 LimitRequestFields 限制。

正常请求（1&nbsp;个 Cookie 头部）：&nbsp; Cookie: session=abc123;&nbsp;user=admin&nbsp; → 计为&nbsp;1&nbsp;个头部字段
攻击请求（2048&nbsp;个 Cookie 分片）：&nbsp; Cookie: a=AAAA... &nbsp; &nbsp;← 分片&nbsp;1&nbsp; Cookie: a=AAAA... &nbsp; &nbsp;← 分片&nbsp;2（索引引用，仅&nbsp;1&nbsp;字节）&nbsp; Cookie: a=AAAA... &nbsp; &nbsp;← 分片&nbsp;3&nbsp; ...&nbsp; Cookie: a=AAAA... &nbsp; &nbsp;← 分片&nbsp;2048&nbsp; → Apache 计为&nbsp;1&nbsp;个头部字段（！）&nbsp; → 但每个分片都重建完整的合并 Cookie 字符串&nbsp; → 旧副本在流清理前一直存活 → 内存指数增长

为什么 Apache 的放大比远高于 NGINX？

NGINX 将每个头部引用计为独立字段，达到 max_headers 上限后拒绝。Apache 将 Cookie 分片合并为 1 个字段，不受计数限制，且每次重组都保留旧副本——导致放大比高出 50 倍以上。

四、影响范围分析

4.1 五大服务器全中招

&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 受影响服务器分布
&nbsp; &nbsp;&nbsp;NGINX&nbsp; &nbsp; &nbsp; &nbsp; ████████████████████████████ &nbsp;35%&nbsp; &nbsp;&nbsp;Apache&nbsp; &nbsp; &nbsp; &nbsp;████████████████████████ &nbsp; &nbsp; &nbsp;30%&nbsp; &nbsp;&nbsp;IIS&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ████████████████ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;20%&nbsp; &nbsp;&nbsp;Envoy&nbsp; &nbsp; &nbsp; &nbsp; ██████ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;8%&nbsp; &nbsp;&nbsp;Pingora&nbsp; &nbsp; &nbsp; ████ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;5%&nbsp; &nbsp; 其他 &nbsp; &nbsp; &nbsp; &nbsp; ██ &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;2%
&nbsp; &nbsp;&nbsp;Shodan&nbsp;搜索: ssl.alpn:"h2"&nbsp;product:nginx,Apache,IIS,Envoy，&nbsp; &nbsp;&nbsp;Pingora&nbsp; &nbsp; 总暴露数:&nbsp;880,000+

4.2 为什么传统防御全部失效

4.3 根本原因：协议规范缺陷

研究团队指出，根本缺陷在 RFC 7541 规范本身。RFC 7541 §7.3 将 SETTINGS_HEADER_TABLE_SIZE 视为唯一的内存边界，完全忽略了每个条目的分配器开销。五个独立团队阅读了同一节规范，犯了同一个错误——这不是实现者的错，而是规范没有定义这个边界。

五、总结

HTTP/2 Bomb（CVE-2026-49975）是 2026 年最值得关注的 Web 基础设施漏洞之一，其核心特征可以概括为三点：

1. AI 发现，人类十年未察

OpenAI Codex 将两个分别存在了近十年的攻击原语——HPACK 压缩炸弹（2016 年命名）和 HTTP/2 流控停顿（2016 年 CVE）——首次组合成一个攻击链。五位独立团队阅读了同一份 RFC 规范，犯了同一个错误。这不是”AI 取代人类”的故事，而是”AI 帮人类看到了他们一直在忽略的东西”。

2. 攻击成本极低，杀伤力极大

一台家用电脑 + 100Mbps 宽带 = 10 秒瘫痪 32GB 服务器。不需要僵尸网络，不需要零日漏洞利用经验，甚至不需要认证。880,000+ 公网暴露的 HTTP/2 服务器全部处于风险之中。

3. 协议级缺陷，传统防御全面失效

WAF、请求频率限制、头部大小限制、DDoS 清洗——全部失效。因为攻击流量完全正常，只是一个”合法但恶意”的 HTTP/2 请求。根本原因在 RFC 7541 规范本身——它没有定义每个条目的分配器开销边界。

如果觉得有用欢迎点赞，转发，有用三连！转发给有需要的师傅，让安全防范于未然！

#

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：挽风安全挽风挽风《HTTP/2 Bomb：AI 拼出十年潜伏的协议级 DoS 核弹，880000+ 服务器一触即溃》