新型“HTTP/2炸弹”攻击可在数秒内耗尽服务器内存

研究人员披露了一种名为 HTTP/2 Bomb 的新型拒绝服务 (DoS) 技术，这是一种内存耗尽攻击，可以在几秒钟内使主要 Web 服务器无法访问。

该攻击会影响 nginx、Apache HTTP Server、Microsoft IIS、Envoy 和 Cloudflare Pingora 的默认 HTTP/2 配置。

该攻击由 Codex 发现，并于 2026 年 6 月 2 日公开披露。安全公司Calif 的研究人员证明，通过 100 Mbps 互联网连接的系统可以在不到一分钟的时间内消耗数十 GB 的服务器内存。该发现归功于 Quang Luong，Jun Rong 和 Duc Phan 则在其他服务器平台上验证了该攻击。

受影响的产品为互联网的很大一部分提供支持。nginx 和 Apache 是部署最广泛的 Web 服务器之一，IIS 在企业环境中仍然很常见，而 Envoy 和 Pingora 则广泛应用于云和代理基础设施。

该攻击结合了两种已知的 HTTP/2 滥用技术。第一种针对 HPACK，即 HTTP/2 的头部压缩机制，它允许使用紧凑索引引用先前传输的头部。攻击者通过将头部插入 HPACK 的动态索引表并引用数千次，可以强制服务器分配远超请求大小所需的内存。

第二阶段利用了 HTTP/2 流量控制机制。攻击者通过通告一个零字节的流量控制窗口，阻止服务器完成响应并释放内存。周期性的单字节 WINDOW_UPDATE 帧维持连接，同时内存分配被占用。

加州

研究人员指出，该攻击的两个组成部分都已公开多年。其新颖之处在于将基于HPACK的内存放大与HTTP/2流控制阻塞相结合，从而形成一种实用的攻击方式，能够在极低的带宽下消耗并占用大量内存。

据 Codex 称，该攻击在测试中取得了以下结果：

Envoy 1.37.2 ~5,700:1（放大倍率） 32 GB 约 10 秒内传输完毕（内存消耗率）
Apache httpd 2.4.67 ~4,000:1，32 GB 数据在约 18 秒内传输完毕。
nginx 1.29.7 ~70:1，32 GB 数据在约 45 秒内传输完毕。
Microsoft IIS（Windows Server 2025）~68:1，64 GB 数据在约 45 秒内传输完毕。

与早期依赖于展开大型压缩值的HPACK压缩炸弹不同，这种新技术利用了服务器端头部处理和簿记所消耗的内存。因此，常见的解码头部大小限制无法阻止这种攻击。

研究人员还发现了一种利用碎片化 Cookie 标头绕过限制的方法。Apache 和 Envoy 对标头数量有限制，但碎片化的 Cookie"残渣"并不计入这些限制，这使得攻击者能够在不超出配置限制的情况下生成数千个分配。

研究人员通过 Shodan 搜索发现，超过 880,000 个面向互联网的主机支持 HTTP/2 并运行受影响的服务器产品之一，尽管其中许多主机受到 CDN 的保护。

nginx 已在 1.29.8 版本中解决了这个问题，该版本引入了一个新的 max_headers 指令。Apache 在 mod_http2 v2.0.41 中修复了该漏洞，确保 cookie 片段计入请求字段限制。该漏洞的编号为 CVE-2026-49975。

披露时，Microsoft IIS、Envoy 或 Cloudflare Pingora 尚无修复方案，但已通知其维护人员。

组织应在有补丁可用的情况下升级受影响的软件。如果无法升级，研究人员建议禁用 HTTP/2，严格限制请求头数量，并对工作进程设置内存限制，以防止单次攻击耗尽系统资源。

Codex 发现了一个隐藏的 HTTP/2 炸弹

Codex Discovered a Hidden HTTP/2 Bomb - Calif

14 年前，我参与破解了 HTTP 头部压缩，之后又被要求审查修复方案，该方案后来成为了 HTTP/2 的一部分。人生兜兜转转又回到了原点：今天我们发布了一个我当年错过的攻击方案。

我们发布了 HTTP/2 Bomb，这是一种针对大多数主流 Web 服务器的远程拒绝服务攻击漏洞，其中包括：

nginx
Apache httpd
微软 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倍速播放）

github-dark-default 复制代码

<span style="background-color:#ffffff"><span style="color:#363737"><span style="background-color:#ffffff"><span style="color:#1f2328"><code>| 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  |</code></span></span></span></span>

鸣谢

感谢 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也存在漏洞。我们已通知了它们的维护者。鉴于从提交到利用的路径如此之短，我们发布此文档，旨在为用户提供以下缓解措施。

缓解措施

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 终止点都应该限制每个请求的头字段数量（包括cookiecrumbs），无论其总大小如何，并且应该限制停滞流的生命周期，无论其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，却错过了这颗重磅炸弹。

Calif | Substack