HTTP/2 Bomb：一个AI发现的漏洞如何威胁全球Web服务器

本文由点滴安全（www.dripsafe.cn）原创发布

引言

2026年6月初，安全公司Calif披露了一个被命名为”HTTP/2 Bomb”的新型拒绝服务攻击手法。这个漏洞的发现过程本身就足够戏剧性——它是由OpenAI的Codex autonomous工具通过链式组合两种已知技术发现的。更令人不安的是，它影响的不只是某一家产品，而是几乎所有主流Web服务器：NGINX、Apache HTTPD、Microsoft IIS、Envoy，甚至Cloudflare的Pingora。

这意味着，全球绝大多数网站和Web服务都暴露在这种攻击之下。

一、HTTP/2 Bomb到底是什么？

HTTP/2 Bomb并非传统意义上的单个漏洞，而是一种巧妙的攻击组合。它将两种已知的攻击技术——压缩炸弹（Compression Bomb）和Slowloris慢速连接攻击——通过HTTP/2协议的特性串联起来，产生了一种此前未被识别的攻击面。

1.1 攻击原理

HTTP/2协议使用一种名为HPACK的专用头部压缩算法。HPACK通过Huffman编码压缩请求和响应的元数据，平均可以减少30%的头部大小。这本是一个提高效率的设计，但恰恰是这个设计被攻击者利用了。

攻击的核心逻辑是：

“线路上一个字节，变成服务器上一个完整的头部分配，每个请求重复数千次。”

具体来说，攻击者构造一个极小的HPACK编码头部，在服务器端解码后会触发大量的内存分配。然后，攻击者利用HTTP/2的流控机制——将流控窗口设置为零字节——让服务器永远无法释放这些已分配的内存。

这就像往一个气球里不断充气，但永远不让它放气，最终气球必然爆炸。

1.2 与传统压缩炸弹的区别

2016年曾出现过类似的HPACK Bomb攻击（CVE-2016-6581），所以主流服务器早就加入了对头部解码大小的限制。但HTTP/2 Bomb绕过了这些防御。

Calif的研究团队解释了关键差异：

“传统的压缩炸弹将一个大值塞入HPACK表然后反复引用它，所以服务器学会了限制总解码头部大小。我们的变种反其道而行之：头部几乎为空，放大效应来自服务器为每个条目分配的簿记开销。解码大小限制永远不会触发，因为几乎没有什么需要解码的。”

这句话揭示了HTTP/2协议设计中的一个深层盲区：规范将内存风险纯粹定义为放大比率问题，但比率只是方程的一半。 一个70:1的放大器如果请求完成后内存能释放，它是无害的。但HTTP/2允许客户端几乎零成本地保持连接打开，将每个已分配字节无限期钉住。

二、攻击影响有多大？

2.1 攻击效率

在假设的攻击场景中，一台家用电脑通过100Mbps宽带连接，就能够在几秒钟内使一台脆弱的服务器不可访问。

更具体的测试数据：单个客户端可以在约20秒内消耗并锁定Apache HTTPD和Envoy服务器上32GB的内存。

这不是什么需要超级计算能力的攻击。一台普通笔记本就够了。

2.2 影响范围

HTTP/2 Bomb影响了几乎所有主流Web服务器：

• NGINX — 全球使用量最高的Web服务器之一
• Apache HTTPD — 老牌Web服务器，仍在大量使用
• Microsoft IIS — Windows生态的核心Web服务
• Envoy — 云原生环境广泛使用的代理
• Cloudflare Pingora — Cloudflare自研的HTTP代理

这个漏洞的默认配置就存在风险，不需要管理员做任何特殊的错误配置。

2.3 现实威胁

拒绝服务攻击虽然不涉及数据泄露，但其对业务的影响不容小觑。对于电商网站，几分钟的宕机就意味着数百万的营收损失。对于SaaS服务，可用性直接关系到客户信任和合同SLA。而且，DoS攻击常被用作更大规模攻击的烟雾弹——在安全团队忙于恢复服务时，真正的入侵可能在另一个方向悄然发生。

三、AI发现漏洞：安全新范式的信号

这个漏洞最引人注目的不仅是其影响范围，更是它的发现方式。

OpenAI Codex——一个自主AI工具——通过将两种已知技术链式组合，发现了这个隐藏在HTTP/2协议实现中的问题。这不是人类安全研究员的灵光一闪，而是AI系统性地探索攻击空间的结果。

这再次印证了2026年安全领域的一个重要趋势：AI正在从攻击者和防御者两个方向同时加速安全研究的节奏。Anthropic的Project Glasswing用Claude在一个月内发现超过10,000个高危漏洞，现在OpenAI Codex又在协议层面发现了影响全球基础设施的问题。

对安全团队而言，这意味着：你的攻击面正在被AI以前所未有的速度探索，无论你是否也在用AI来防御。

四、如何防御？

4.1 紧急缓解措施

针对各服务器的修复建议：

NGINX 升级到1.29.8或更高版本。新版本增加了max_headers指令，默认值为1000。如果暂时无法升级，可以在配置中禁用HTTP/2：

http2 off;

Apache HTTPD 升级mod_http2到v2.0.41。如果无法升级，在配置中禁用HTTP/2：

Protocols http/1.1

Microsoft IIS、Envoy、Cloudflare Pingora 截至本文撰写时，这些平台尚无可用的补丁。建议密切关注厂商公告，在条件允许时暂时回退到HTTP/1.1。

4.2 架构层面的思考

HTTP/2 Bomb暴露的不只是某个具体实现的问题，而是HTTP/2协议设计中的一个结构性盲区。未来HTTP/3（基于QUIC）是否会继承类似的问题，值得持续关注。

从架构层面，以下几点值得所有安全团队反思：

1. 协议设计需要考虑资源锁定时间，而不仅仅是单次请求的放大比率
2. 默认配置应该是安全的——不应依赖管理员去手动调整参数来防御未知攻击
3. 内存资源需要有硬性上限——即使协议允许客户端无限期持有连接，服务器端也应有保护机制

五、对中国企业的特别提醒

中国企业的Web基础设施中，NGINX和Apache的使用率极高，尤其是在互联网公司和云服务提供商中。以下几点需要特别关注：

1. 立即排查：清点所有对公网暴露的HTTP/2服务器，确认版本号
2. 优先级排序：先处理直接暴露在互联网上、承载高价值业务的服务器
3. 补丁测试：NGINX的max_headers指令和HTTP/2禁用都可能在某些配置下产生副作用，建议在测试环境验证后再上线
4. CDN保护：如果使用了CDN（如阿里云CDN、腾讯云CDN），确认CDN供应商已经或计划修补此问题
5. 监控加强：在WAF和流量监控中增加对异常HTTP/2连接模式的检测规则

结语

HTTP/2 Bomb是一个教科书级的案例：它不是某个具体的代码bug，而是协议设计中的结构性缺陷与实现细节交互产生的安全盲区。更重要的是，它是由AI自主发现的——这预示着安全研究的自动化正在进入一个新阶段。

对于安全从业者而言，这不是一个可以”打完补丁就忘掉”的漏洞。它提出了一个更深层的问题：当AI能够系统性地探索协议实现的攻击面时，我们是否需要重新审视所有在用的网络协议？

答案可能是肯定的。但在那一天到来之前，先把你的NGINX和Apache升级了。

参考来源： – Calif Blog: Codex Discovered a Hidden HTTP/2 Bomb – The Hacker News: New HTTP/2 Bomb Vulnerability Allows Remote DoS on NGINX, Apache, IIS, Envoy & Cloudflare – Redis Security Advisory: CVE-2026-23479 – NVD: CVE-2016-6581, CVE-2025-53020

本文由点滴安全（www.dripsafe.cn）技术团队出品，关注我们获取更多网络安全深度分析。