来源: Codex Discovered a Hidden HTTP/2 Bomb - Calif
我们发布了 HTTP/2 Bomb，这是一种针对大多数主流 Web 服务器的远程拒绝服务攻击漏洞，其中包括：
- nginx
- Apache httpd
- Microsoft IIS
- Envoy
- Cloudflare Pingora
每个服务器的默认 HTTP/2 配置中都存在这种漏洞。
该攻击由 Codex 发现，它结合了两种人类已知十年的技术：压缩炸弹和类似 Slowloris 的锁定机制。压缩炸弹的目标是 HTTP/2 的头部压缩方案 HPACK：网络上传输的一个字节会在服务器上占用一个完整的头部空间，每个请求重复数千次。锁定机制则是一个零字节的流量控制窗口，阻止服务器释放任何占用的空间。
在 Shodan 上进行的一次有趣的搜索显示，有超过 88 万个网站支持 HTTP/2 并运行着这些服务器之一，尽管其中许多网站位于 CDN 之后，而 CDN 更难被摧毁。
一台家用电脑，即使连接速度只有 100Mbps，也能在几秒钟内使存在漏洞的服务器无法访问。针对 Apache httpd 和 Envoy，单个客户端可以在大约 20 秒内消耗并占用服务器 32GB 的内存。
从左上角顺时针方向依次为：Apache httpd、Envoy、nginx、Microsoft IIS。（2倍速播放）
| Server | Amplification | Demo result |
|-------------------------------------|---------------|----------------|
| Envoy 1.37.2 | ~5,700:1 | ~32 GB in ~10s |
| Apache httpd 2.4.67 | ~4,000:1 | ~32 GB in ~18s |
| nginx 1.29.7 | ~70:1 | ~32 GB in ~45s |
| Microsoft IIS (Windows Server 2025) | ~68:1 | ~64 GB in ~45s |
鸣谢
- 感谢 Quang Luong 发现了这个漏洞。他将在六月于斯坦福大学举行的“真实世界人工智能安全大会”上展示他的技术。
- 感谢 Jun Rong 和 Duc Phan 确认了对其他网络服务器的攻击。
技术细节
HPACK（RFC 7541 ）是一种有状态压缩方案。HTTP/2 连接的每一方都维护一个动态的头部表，记录最近访问过的头部信息。发送方只需将一个头部信息插入该表一次，然后在后续请求中通过索引（通常是一个字节）引用它。接收方查找索引，并将完整的头部信息副本添加到它正在构建的请求中。
HTTP/2 本身（RFC 9113 ）增加了基于流的流量控制：接收方声明一个窗口，发送方在收到响应之前无法发送超出该窗口的数据WINDOW_UPDATE 。关键在于，客户端控制着服务器响应的窗口。
这些功能中的每一个都有已知的滥用模式，而该漏洞利用程序将这些模式串联起来：
- HPACK 索引引用炸弹 ：攻击者先用一个表头填充动态表，然后向该表发送数千个 1 字节的索引引用。每个引用都会消耗攻击者 1 个字节的带宽，并给服务器分配约 70 字节（nginx、IIS、Pingora）到约 4000 字节（Apache httpd、Envoy）的内存。
- HTTP/2 窗口停滞 ：通告一个零字节的流控制窗口，使服务器永远无法完成其响应的发送，然后以 1 字节的
WINDOW_UPDATE帧不断重置发送超时，将内存中的每次分配锁定到服务器超时允许的时间内。
这些并非全新问题。Cory Benfield 于 2016 年提出了“HPACK 炸弹”的概念，并附上了CVE-2016-6581 漏洞报告。2025 年，Gal Bar Nahum 又发现了针对 Apache httpd的 CVE-2025-53020 漏洞（修复说明），该漏洞利用率约为 4000 倍。HTTP/2 Slowloris 类型的资源耗尽漏洞（不包含压缩放大器）也同样由来已久：CVE-2016-8740漏洞利用了无限制的 CONTINUATION 帧，CVE-2016-1546 漏洞则利用了工作线程饥饿，这两个漏洞都存在于 Apache httpd 中。
这里的新颖之处在于放大效应的来源。传统的炸弹会将一个很大的值塞进表中并反复引用它，因此服务器学会了限制解码后的头部总大小。我们的变体则反其道而行之：头部几乎为空，放大效应来自服务器围绕每个条目分配的簿记空间。由于几乎没有东西需要解码，解码大小的限制永远不会触发。
对于那些限制头部字段数量的服务器（例如 Apache 和 Envoy），Cookie 有一种绕过限制的方法：RFC 9113 §8.2.3明确允许将 Cookie 头部拆分成每个 crumb 一个字段，而这些服务器并没有将 crumb 计入限制。接下来的放大倍数取决于服务器如何重新组装 cookie。Envoy 将每个 crumb 追加到一个缓冲区中，因此一个 4 KB 的 cookie 值被引用 32k 次，逻辑上会得到约 3,600:1 的比例（最终 cookie 字节数与网络传输字节数之比）；实际测量的 RSS 比率更高：跨流约为 3,800:1，在单个流上，一旦加上分配器开销，最高可达约 5,700:1。Apache httpd 会在每个 crumb 上重建整个合并字符串，使每个旧副本保持有效，直到流被清理，因此即使是空 cookie 也会导致约 4,000:1 的比例。
在实际攻击中，你可能根本不希望进程内存溢出（OOM），因为被杀死的进程会重新启动。更有效的策略是将内存压力控制在略低于崩溃阈值的水平，将进程推入交换空间，并让机器上的其他请求缓慢执行。
概念验证
您可以在这里找到每个服务器的 AI 生成的文档、Docker 实验室和 PoC 脚本。
请不要将这些指向您不拥有的基础设施。
披露
我们在四月份向 nginx 披露了这个问题。他们随后从freenginx导入了该max_headers 指令，并在第二天将其发布到 1.29.8 版本中。至此，我们认为该攻击已公开。
我们于 5 月 27 日向 Apache 披露了此问题，Stefan Eissing当天就通过调整cookie 响应头数量修复了该漏洞LimitRequestFields 。该漏洞的编号为 CVE-2026-49975。
上述修复提交是公开的，直接暴露了攻击向量；任何有能力的AI模型都可以将这些差异转化为可用的漏洞利用程序，而我们也正是通过这种方式发现Microsoft IIS、Envoy和Pingora也存在漏洞。我们已通知了它们的维护者。鉴于从提交到利用的路径如此之短，我们发布此文档，旨在为用户提供以下缓解措施。
2026年6月3日更新 ：Envoy已发布补丁，似乎可以缓解此次攻击。我们正在更仔细地验证该修复方案，如果发现任何剩余漏洞，我们将更新此帖。
缓解措施
nginx ：请升级到 1.29.8+ 版本，该版本添加了max_headers 默认值为 1000 的指令。如果无法升级，请使用以下命令禁用 HTTP/2 http2 off; 。
Apache httpd ：此修复程序已包含在 mod_http2 v2.0.41 中，可从独立的 mod_http2 版本和 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 活动如何。如果目前无法做到以上任何一点，则应ulimit -v 严格限制每个工作进程的内存使用量（cgroups、容器限制等），以确保发生内存溢出的工作进程在占用整个服务器空间之前被内核强制终止并重新启动。一个工作进程很少需要几 GB 的内存；让内核尽早终止一个工作进程比让攻击者将整个服务器的资源占用率维持在 95% 要好得多。
要点总结
RFC 7541 专门用一整节来讨论这种威胁。§7.3内存消耗部分开头写道：“攻击者可以尝试耗尽端点的内存”，然后解释说 HPACK 通过某种方式限制动态表SETTINGS_HEADER_TABLE_SIZE ，并认为这个问题已经得到解决。但是，当五个独立的实现都阅读了该部分内容，却仍然出现同一类型的错误时，问题就出在规范本身。
更深层次的误解在于，规范将内存风险仅仅视为一个放大倍数，而放大倍数只是问题的一半。如果请求完成后内存被释放，那么 70:1 的放大倍数是无害的。但当 HTTP/2 允许客户端几乎免费地保持连接打开状态，并根据需要占用每个已分配的字节时，它就变成了一种攻击。
另一点值得注意的是这个漏洞是如何被发现的。这两个部分都已公开十年之久。Codex 所做的，是阅读代码库，发现两者可以组合使用，并构建出组合攻击。这种组合方式显而易见，但据我们所知，此前没有人利用它攻击过这些服务器。
结语
当团队向我介绍这项研究时，我仿佛回到了2012年。那一年，我和朱利亚诺·里佐发现了CRIME ，一个可以从压缩的HTTP头部中恢复cookie的压缩预言机。当时我在谷歌工作，所以被要求审查修复方案，也就是后来的HPACK。我刚刚重新翻阅了当时的审查笔记：我竟然从未考虑过这种攻击。我当时一心只想对抗CRIME，却错过了这颗重磅炸弹。