2026-10-21 23:30:57 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

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（严重级）。

核心数据：

指标	数值
受影响 Web 服务器	NGINX、Apache HTTPD、IIS、Envoy、Cloudflare Pingora
公网暴露实例	880,000+
攻击所需带宽	100Mbps（家用宽带即可）
Apache/Envoy 放大比	4,000:1 ~ 5,700:1
单客户端打瘫 32GB 服务器	10 秒（Envoy）/ 18 秒（Apache）
攻击成本	一台笔记本电脑 + 一条宽带

这个漏洞的可怕之处在于：攻击者不需要僵尸网络，不需要零日漏洞利用经验，甚至不需要认证——只需要一台家用电脑和一条百兆宽带，就能在 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  HPACK Bomb（大值填充 → 解码大小限制，被修复）2016: CVE-2016-8740  无界 CONTINUATION 帧（Apache，被修复）2016: CVE-2016-1546  工作线程饥饿（Apache，被修复）2025: CVE-2025-53020 Apache HTTP/2 内存耗尽（Gal Bar Nahum，4,000x 放大）2026: CVE-2026-49975 HTTP/2 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 攻击机制全景图

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

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

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

┌──────────────────────────────────────────────────┐│              HPACK 动态表                         │├──────┬───────────────────────────────────────────┤│ 索引 │ 头部名称     │ 头部值                      │├──────┼──────────────┼────────────────────────────┤│  62  │ :method      │ GET                         ││  63  │ :path        │ /                           ││  64  │ cookie       │ a=AAAA...(4058 字节)        │  ← 攻击者插入│  65  │ user-agent   │ Mozilla/5.0...               ││  ... │ ...          │ ...                         │└──────┴──────────────┴────────────────────────────┘
# 攻击者后续发送：# 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  (共 4064 字节)COOKIE_VALUE = \"a=\" + \"A\" * 4058  # 4064 字节
# 攻击者随后在一个请求中发送 2048 个 Cookie 分片（RFC 9113 允许）# 每个分片仅包含 1 字节的 HPACK 索引引用NUM_CRUMBS = 2048
# 网络流量（攻击者发送）wire_bytes = NUM_CRUMBS * 1  # 2048 字节
# 服务器分配（Apache 对每个分片重建完整 Cookie 字符串）server_allocation = 0# Apache 每个分片都重建完整合并 Cookie 字符串# 旧副本在流清理前一直存活for i in range(NUM_CRUMBS):    # 每个分片强制服务器重建完整 Cookie    server_allocation += len(COOKIE_VALUE)  # 4064 字节
# 放大比amplification = server_allocation / wire_bytesprint(f\"网络流量: {wire_bytes} 字节 ({wire_bytes/1024:.1f} KB)\")print(f\"服务器分配: {server_allocation} 字节 ({server_allocation/(1024*1024):.1f} MB)\")print(f\"放大比: {amplification:.0f}:1\")print(f\"内存锁定: 攻击者设置 INITIAL_WINDOW_SIZE=0，内存永不释放\")
# 输出示例:# 网络流量: 2048 字节 (2.0 KB)# 服务器分配: 8323072 字节 (7.9 MB)# 放大比: 4064:1# 内存锁定: 攻击者设置 INITIAL_WINDOW_SIZE=0，内存永不释放

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

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

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

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

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

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

四、影响范围分析

4.1 五大服务器全中招

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

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

防御手段	为什么失效
WAF / 请求频率限制	攻击只需 1 个请求，低频低流量
头部大小限制	单个头部值很小，解码大小限制不触发
头部数量限制	Cookie 分片被合并为 1 个字段，绕过计数
请求体大小限制	攻击不涉及请求体
并发连接限制	1 个连接即可完成攻击
DDoS 清洗	流量特征完全正常，无异常模式

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 规范本身——它没有定义每个条目的分配器开销边界。