2026年6月3日，安全研究人员公开披露了一个被命名为"HTTP/2 Bomb"的高危拒绝服务漏洞（CVE-2026-49975），该漏洞影响 nginx、Apache httpd、IIS、Envoy Proxy 乃至 Cloudflare Pingora 等几乎所有主流 Web 服务器和代理平台。仅需一条家用宽带连接，攻击者就能在数十秒内耗尽一台拥有 32GB 内存的服务器，将其彻底瘫痪。本文将从技术原理、危害评估和企业应对策略三个维度，对此事件进行全面解析。
一、漏洞速览
| 维度 | 详情 |
|---|---|
| CVE 编号 | CVE-2026-49975 |
| 漏洞名称 | HTTP/2 Bomb（HTTP/2 炸弹） |
| 披露日期 | 2026年6月3日（协调披露，厂商提前7天获通知） |
| 漏洞类型 | 远程拒绝服务（DoS），利用 HTTP/2 HPACK 协议特性 |
| 受影响平台 | nginx、Apache httpd、Microsoft IIS、Envoy Proxy、Cloudflare Pingora |
| 暴露规模 | Shodan 扫描确认超 880,000 台公网服务器受影响 |
| PoC 状态 | 已随报告公开发布，攻击门槛极低 |
| 补丁状态 | 各厂商独立修复中，尚无统一补丁 |
二、攻击原理深度解析
要理解这个漏洞为什么如此危险，需要先了解 HTTP/2 协议的一项核心设计——HPACK 头部压缩。
HTTP/2 为了提高传输效率，使用 HPACK 算法对请求和响应头部进行压缩。简单来说，HPACK 维护了一个动态表来存储已传输过的头部字段，后续请求只需发送一个简短的索引引用，服务器就能还原出完整头部。这本是一个优雅的性能优化设计，但恰恰成为了攻击者的突破口。
CVE-2026-49975 的攻击分为两个阶段：
- HPACK 压缩表放大（Table Amplification）：攻击者首先向目标服务器发送一个包含超大头部条目的 HTTP/2 请求，将其"植入"服务器的 HPACK 动态压缩表中。此后，攻击者发送数千个单字节引用指向这个巨型条目，迫使服务器为每一个引用重新分配内存、重建完整头部。
- Slowloris 式连接保持：攻击者在内存被逐步耗尽的过程中，持续保持连接存活，使服务器无法释放已被占用的内存资源，形成"温水煮青蛙"式的渐进式崩溃。
不同平台的放大比率差异极大，这也决定了各平台面临的即时风险等级：
| 平台 | 带宽放大比率 | 实际危害描述 |
|---|---|---|
| Envoy Proxy | 5,700:1 | 单条家庭宽带，约10秒耗尽32GB内存 |
| Apache httpd | 4,000:1 | 极高危害，边缘网关场景首当其冲 |
| nginx | 70:1 | 单连接产生数Mbps流量，可降级服务 |
| IIS / Pingora | 待确认 | 微软和Cloudflare在独立跟踪修复 |
从表中可以看出，nginx 的放大比率（70:1）远低于 Envoy 的 5,700:1，但这不意味着 nginx 用户就可以高枕无忧——攻击者完全可以发起多连接并发攻击，通过多条连接同时对一台 nginx 服务器施压，达到同样的瘫痪效果。关键在于：攻击成本极低，但防御成本很高。
三、为什么这是一个"里程碑"级别的漏洞
我们认为 CVE-2026-49975 值得所有 IT 运维人员高度关注，原因如下：
- 无法通过配置关闭：HPACK 头部压缩是 HTTP/2 协议的强制性核心特性，不是可选扩展。只要你的服务器开启了 HTTP/2（现代 Web 服务器默认开启），就天然具备这个攻击面。修复必须深入到代码实现层面，不能靠"改个配置"解决。
- 攻击门槛极低：研究人员随报告公开发布了 PoC 代码。这意味着任何具备基本网络知识的人都可以复现攻击——不需要僵尸网络，不需要购买DDoS服务，一根家用宽带就够。
- 覆盖面史无前例：不像以往的漏洞只影响某一款软件，HTTP/2 Bomb 的攻击面覆盖了整个 HTTP/2 生态系统。从 Apache 到 nginx，从 IIS 到 Envoy，从自建机房到 Cloudflare 边缘节点，无一幸免。
- CDN 前置防护失效：Cloudflare 自家的 Pingora 代理引擎同样受影响。这意味着即使你套了 CDN，如果 CDN 本身处理 HTTP/2 连接的组件存在此漏洞，防护效果将大打折扣。
四、IT 管理员应对策略
面对目前尚无统一补丁的局面，我们建议企业 IT 管理员立即采取以下分级措施：
第一优先级：排查与评估（立即执行）
- 确认所有对外提供 Web 服务的服务器是否启用了 HTTP/2（检查 nginx 配置中的
http2指令、Apache 的Protocols h2配置等） - 重点排查使用 Envoy 或 Apache 作为边缘网关/API 网关的服务器——它们是最高风险目标
- 通过 Shodan 等工具自查公网暴露面
第二优先级：临时缓解（24小时内）
- 在 WAF 或反向代理层设置 HTTP/2 连接数限制和单个连接的请求数上限
- 加大服务器内存和连接数监控告警，设置异常流量自动触发预案
- 如业务允许，临时在边缘网关降级到 HTTP/1.1（需评估兼容性影响）
第三优先级：持续跟进（每日关注）
- 订阅 nginx、Apache、微软、Envoy 官方安全公告，等待补丁发布后第一时间升级
- 关注 CISA KEV 目录动态，该漏洞有较高概率被列入已知利用漏洞清单
- 将本次事件纳入团队安全培训案例——这是一个极好的"协议层面安全"教材
五、我们的观点
作为长期服务北京地区中小企业 IT 运维的团队，我们认为 CVE-2026-49975 暴露了一个被长期忽视的安全盲区：协议层面的安全威胁。大多数企业的安全防护仍然停留在应用层（WAF、代码审计）和网络层（防火墙、DDoS清洗），但很少有人关注到——协议本身的设计缺陷同样可以成为攻击入口。
更值得警惕的是，HTTP/2 Bomb 的攻击模式与传统的 DDoS 有本质区别：它不是靠流量"冲垮"服务器，而是通过巧妙地利用协议机制"诱骗"服务器自己耗尽资源。这种"精巧"的攻击更难以被传统的流量清洗设备识别和阻断。
我们的核心建议是：不要把安全等同于"装个防火墙"。真正有效的安全策略，应该覆盖协议层、应用层、系统层和数据层的全栈防护，并建立快速响应机制。漏洞永远会有，但响应速度决定了损失的大小。
如果您负责的服务器使用了 nginx、Apache 或其他受影响的 Web 平台，建议立即启动排查流程。如需技术支持，欢迎通过我们的留言板或电话联系。