Codex 发现 HTTP/2 炸弹：可使百万台服务器瘫痪

导语：HTTP/2 作为主流 Web 服务器的标配协议，存在一个几乎无解的放大攻击漏洞。攻击者只需 100Mbps 带宽，就能在几十秒内让服务器消耗 32GB 内存——这意味着你家那台老旧笔记本，也能让一台高配服务器跪下。

一、事件概述

十四年前，我参与了破解 HTTP 头部压缩的工作，之后又被请去审查那个修复方案——后来的 HPACK 就是这么来的。历史总是惊人地相似：今天，我们发布了一种连我自己都漏掉的攻击。

我们发现的这个漏洞叫做 HTTP/2 Bomb（HTTP/2 炸弹），这是一种针对主流 Web 服务器的远程拒绝服务（DoS）攻击，影响范围包括：

nginx
Apache httpd
微软 IIS（Internet Information Services）
Envoy（代理服务器）
Cloudflare Pingora

这些服务器的默认 HTTP/2 配置全都存在漏洞。

该攻击由安全研究团队 Codex（科多克斯） 发现，结合了两种已公开十年的技术：压缩炸弹和类似 Slowloris（慢速拒绝服务） 的连接锁定机制。压缩炸弹的目标是 HTTP/2 的头部压缩方案 HPACK（头部压缩协议）：网络上传输的一个字节，会在服务器上占用一个完整的头部空间，如果每个请求重复数千次，效果可想而知。锁定机制则是一个零字节的流量控制窗口，阻止服务器释放任何已占用的空间。

HTTP/2 炸弹攻击效果对比：从左上角顺时针依次为 Apache httpd、Envoy、nginx、Microsoft IIS（2倍速播放）

从左上角顺时针方向依次为：Apache httpd、Envoy、nginx、Microsoft IIS（2倍速播放）

Shodan 的搜索数据显示，有超过 88 万个网站 支持 HTTP/2 并运行上述服务器之一。虽然其中许多网站位于 CDN 之后，CDN 更难被直接攻击，但这个数字依然触目惊心。

关键数据：一台普通家用电脑，即使只有 100Mbps 的带宽，也能在几秒钟内让存在漏洞的服务器彻底无法访问。针对 Apache httpd 和 Envoy，单个客户端只需约 20 秒，就能消耗并占用服务器 32GB 的内存。

二、技术原理

HPACK 是什么

HPACK（RFC 7541） 是一种有状态的头部压缩方案。HTTP/2 连接的每一方都维护一个动态表，记录最近发送的头部信息。发送方只需将头部插入表一次，后续请求只需发送一个索引（通常只有 1 字节）来引用它，接收方再通过索引查找完整的头部副本。

HTTP/2 本身（RFC 9113）增加了基于流的流量控制：接收方声明一个窗口，发送方必须收到 WINDOW_UPDATE 帧后才能继续发送数据。关键在于，客户端控制着服务器响应的窗口大小。

攻击链：两种手法叠加

这两个功能单独都有已知的滥用模式，而 Codex 将它们串联起来，形成了致命的组合攻击：

第一种：HPACK 索引引用炸弹

攻击者先用头部填充动态表，然后向该表发送数千个 1 字节的索引引用。每个引用只消耗攻击者 1 个字节的带宽，但给服务器分配约 70 字节（nginx、IIS、Pingora）到约 4000 字节（Apache httpd、Envoy）的内存。

第二种：HTTP/2 窗口停滞

攻击者通告一个零字节的流控制窗口，使服务器永远无法完成响应的发送。然后以 1 字节的 WINDOW_UPDATE 帧不断重置发送超时，将内存中的每次分配锁定到服务器允许的超时时间。

新颖之处：放大效应来源不同

传统的压缩炸弹会将一个超大值塞进表中反复引用，服务器学会了限制解码后的头部总大小。但 Codex 的变体反其道而行：头部几乎为空，放大效应来自服务器围绕每个条目分配的簿记空间（bookkeeping space）。由于几乎没有东西需要解码，解码大小的限制永远不会触发。

对于那些限制头部字段数量的服务器（如 Apache 和 Envoy），有一种绕过方法：Cookie 字段可以拆分——RFC 9113 §8.2.3 明确允许将 Cookie 头部拆成每个 crumb 一个字段，而这些服务器并没有将 crumb 计入限制。

具体放大倍数取决于服务器如何重新组装 cookie：

Envoy：将每个 crumb 追加到缓冲区，一个 4KB 的 cookie 值被引用 32k 次，逻辑比例约 3,600:1；实际测量的 RSS（进程内存占用）比例更高，跨流约 3,800:1，单个流加上分配器开销可达约 5,700:1。
Apache httpd：在每个 crumb 上重建整个合并字符串，每个旧副本保持有效直到流被清理，即使是空 cookie 也能导致约 4,000:1 的比例。

实战策略

在实际攻击中，攻击者可能不希望进程内存溢出（OOM），因为被杀死的进程会重新启动。更有效的策略是：将内存压力控制在略低于崩溃阈值的水平，将进程推入交换空间，让机器上的其他请求缓慢执行——这种”慢性失血”比直接致瘫更难被察觉。

三、历史漏洞回顾

这些并非全新问题：

年份	漏洞编号	类型	影响
2016	CVE-2016-6581	HPACK 炸弹	首次提出”HPACK 炸弹”概念
2025	CVE-2025-53020	HPACK 轰炸	针对 Apache httpd，利用率约 4000 倍
2016	CVE-2016-8740	CONTINUATION 帧耗尽	无限制 CONTINUATION 帧
2016	CVE-2016-1546	工作线程饥饿	HTTP/2 Slowloris 类型

四、漏洞披露与修复

时间线

四月份：向 nginx 团队披露。nginx 随后从 FreeBSD 导入了 max_headers 指令，并在第二天发布了 1.29.8 版本修复该问题。
5 月 27 日：向 Apache 披露。Stefan Eissing 当天就通过调整 LimitRequestFields 中的 cookie 响应头数量修复了该漏洞，分配了 CVE-2026-49975。
2026 年 6 月 3 日更新：Envoy 已发布补丁，似乎可以缓解此次攻击。

注意：上述修复提交是公开的，直接暴露了攻击向量。任何有能力的 AI 模型都可以将这些差异转化为可用的漏洞利用程序。Codex 正是通过这种方式发现了 Microsoft IIS、Envoy 和 Pingora 也存在漏洞，并已通知了它们的维护者。

五、缓解措施

nginx：升级到 1.29.8+ 版本，该版本添加了 max_headers 指令（默认值 1000）。如果无法升级，使用 http2 off; 禁用 HTTP/2。

Apache httpd：mod_http2 v2.0.41 已包含修复，可从独立版本和 httpd 主干版本获取（2.4.x 尚未包含）。如果无法升级，使用 Protocols http/1.1 禁用 HTTP/2。降低 LimitRequestFieldSize 会缩小攻击范围（限制合并的 cookie 数量，从而限制 crumb 计数），但这只是部分缓解。降低 LimitRequestFields 在此处无效——重复的 cookie crumb 永远不会被计入限制。

Microsoft IIS、Envoy、Cloudflare Pingora：截至撰写本文时，尚无补丁。如果可以，禁用 HTTP/2，或在服务器前端强制限制每个请求的头部数量。

通用建议：

“最大解码头大小”和”最大头数量”是两个不同的限制，服务器需要同时满足。
任何 HTTP/2 终止点都应该限制每个请求的头字段数量（包括 cookie crumbs），无论其总大小如何。
应该限制停滞流的生命周期，无论其 WINDOW_UPDATE 活动如何。
如果目前无法做到以上任何一点，应严格限制每个工作进程的内存使用量（cgroups、容器限制等），确保 OOM 的工作进程在占用整个服务器之前被内核强制终止并重新启动。一个工作进程很少需要几 GB 的内存——让内核尽早终止一个工作进程，比让攻击者将整个服务器的资源占用率维持在 95% 要好得多。