HTTP/2 Bomb：影响NGINX、Apache、IIS等主流服务器的远程DoS攻击

6/3/2026安全漏洞HTTP/2DoS

HTTP/2 Bomb

安全研究人员披露了一个名为 HTTP/2 Bomb 的远程拒绝服务攻击，影响 NGINX、Apache httpd、Microsoft IIS、Envoy 和 Cloudflare Pingora 的默认 HTTP/2 配置。攻击由 OpenAI Codex 自主发现，将两种已知超过十年的技术组合成了一个此前未被人类组装过的攻击链。

Apache httpd 的漏洞已被分配 CVE-2026-49975。

攻击原理

HTTP/2 Bomb 由两部分组成：

HPACK 索引引用炸弹：HTTP/2 使用 HPACK（RFC 7541）做头部压缩。发送方将一个头部插入动态表后，可以用 1 字节的索引引用它。攻击者向动态表种入一个头部，然后在单个请求中发射数千个 1 字节索引引用。每个引用在客户端侧只花 1 字节带宽，但服务器必须为每次引用分配一份完整的头部副本——nginx/IIS/Pingora 约 70 字节，Apache httpd/Envoy 约 4000 字节。

HTTP/2 窗口停滞：RFC 9113 定义了每流流量控制。客户端通告零字节流量控制窗口，使服务器永远无法完成响应并释放内存。然后周期性地发送 1 字节 WINDOW_UPDATE 帧来重置发送超时，将每个分配的字节钉在内存中。

单独来看这两种技术都不新鲜，但组合在一起产生了此前没有的攻击效果。经典的 HPACK 炸弹向动态表塞入大值，服务器通过限制解码头部总大小来防御。HTTP/2 Bomb 的变体反其道而行——头部几乎为空，放大效应来自服务器为每个条目分配的 bookkeeping 开销。解码大小限制根本不会触发，因为几乎没有什么需要解码的。

对于通过头部字段数量上限来防御的服务器（Apache、Envoy），攻击使用 Cookie 头部作为绕过手段。RFC 9113 §8.2.3 明确允许将 Cookie 拆分为每个 crumb 一个字段，而这两个服务器都没有将 crumb 计入字段限制。

Envoy 将每个 crumb 追加到缓冲区中，单个流上放大比可达约 5700:1。Apache httpd 在每个 crumb 上重建整个合并字符串，同时保留旧副本直到流清理，即使空 Cookie 也能达到约 4000:1 的放大比。

放大效果实测

服务器放大比实测结果
Envoy 1.37.2~5700:1~32GB 内存 / ~10秒
Apache httpd 2.4.67~4000:1~32GB 内存 / ~18秒
nginx 1.29.7~70:1~32GB 内存 / ~45秒
Microsoft IIS (Server 2025)~68:1~64GB 内存 / ~45秒

Shodan 查询显示有超过 88 万个 HTTP/2 端点运行上述服务器（许多位于 CDN 后方）。

修复和缓解方案

nginx：升级到 1.29.8+（新增 max_headers 指令，默认上限 1000）。无法升级则设置 http2 off;。

Apache httpd：部署 mod_http2 v2.0.41（独立发布版本可用）。无法升级则设置 Protocols http/1.1 禁用 HTTP/2。注意仅降低 LimitRequestFields 无效——Cookie crumb 不计入该限制。

Microsoft IIS、Envoy、Cloudflare Pingora：目前无补丁。建议禁用 HTTP/2，或在前面放置一个强制执行请求头部数量硬上限的代理。

通用建议：同时限制最大解码头部大小和最大头部字段数量，独立计数。限制停滞流的生命周期（不因 WINDOW_UPDATE 活动而重置超时）。使用 cgroups、ulimit -v 或容器限制限制每个 worker 的内存——OOM kill 被轰炸的 worker 比让整个机器进入 swap 更好。

协议规范层面的问题

研究人员指出，RFC 7541 §7.3 将内存风险仅表述为放大比，并将 SETTINGS_HEADER_TABLE_SIZE 视为充分约束。它没有考虑每个条目的 bookkeeping 开销，五个独立实现读取同一段规范并犯了同样的错误。

来源：Calif · The Hacker News · CyberSecurityNews

相关推荐