HTTP/2 Bomb漏洞席卷多款Web服务器，Nginx/Apache/IIS均受影响

最近 Web 服务器相关安全问题真的有点密集。本来这次 HTTP/2 Bomb，我其实没太想单独再发一条。

因为前段时间我们已经提醒过，Nginx 升级到包含前面N个CVE修复的安全版本后，本身就可以规避掉这类风险的一部分影响。按理说，如果平时有跟进升级，问题未必会那么明显。

但就在上午在用户群里还是看到有人反馈，前几天已经被这个问题打挂了 2 台机器。

图片来源于网络,版权归原作者所有,侵权请联系删除

这也说明，这次风险并不只是"理论上存在"，而是真的已经影响到实际线上环境了。所以，还是有必要单独再提醒一次：如果你的站点开启了 HTTP/2，请尽快检查当前 Web 服务版本和相关配置。

这次公开披露的问题叫做 HTTP/2 Bomb，是一种针对 HTTP/2 的拒绝服务攻击。

它不是只影响某一个 Web 服务，而是涉及多款主流 Web 中间件，包括 Nginx、Apache HTTP Server、Microsoft IIS、Envoy、Cloudflare Pingora 等。

其中，Apache HTTP Server / mod_http2 侧对应的漏洞编号为 CVE-2026-49975。也就是说，CVE-2026-49975 是 Apache 侧的具体漏洞编号；而 HTTP/2 Bomb 这个攻击面影响范围更广，不能简单理解成"只影响 Apache"。

这个问题危险在哪？

HTTP/2 Bomb 的核心影响是拒绝服务，也就是让服务器资源被快速消耗，最终导致网站变慢、连接异常，严重时服务不可访问。

它主要组合利用了两类机制：

一类是 HPACK 头部压缩放大。

HTTP/2 为了提升传输效率，会对请求头进行压缩。攻击者可以利用这一点，用相对较小的网络请求，触发服务器端解析和分配大量请求头相关内存。

另一类是 HTTP/2 流控停滞。

攻击者可以通过控制 HTTP/2 流量窗口，让服务器已经分配出去的资源迟迟无法释放。这样一来，服务器内存就会被不断占住，最终被拖垮。

简单说，就是攻击者不一定需要特别大的带宽，也不一定需要大量机器，就可能让服务器分配并保留大量内存资源。

公开测试数据显示，在 100Mbps 连接条件下，单个客户端就可能让部分服务在几十秒内分配并保留数十 GB 内存资源。测试中，Envoy 1.37.2 约 10 秒即可耗尽 32GB 内存，Apache httpd 2.4.67 约 18 秒耗尽 32GB 内存。

这不是直接拿服务器权限，也不是远程代码执行，但对于线上业务来说，网站打不开、接口不可用，本身就已经是很严重的问题。

图片来源于网络,版权归原作者所有,侵权请联系删除

影响范围

本次 HTTP/2 Bomb 攻击主要影响开启 HTTP/2 的 Web 服务环境。

公开披露中提到的受影响对象包括：

• Nginx
• Apache HTTP Server
• Microsoft IIS
• Envoy
• Cloudflare Pingora

如果你的服务器正在使用上述 Web 服务，并且站点开启了 HTTP/2，就建议尽快检查当前版本和配置。

尤其是以下几类环境，需要重点关注（HTTP/2通常启用HTTPS证书后会同步开启）：

使用 Nginx 并开启 HTTP/2 的站点；使用 Apache HTTP Server 并开启 HTTP/2 的站点；前面挂了 Envoy、IIS、Pingora 等 HTTP/2 网关或反向代理的环境；HTTPS 站点中启用了 HTTP/2，但长期没有升级 Web 服务版本的环境。

图片来源于网络,版权归原作者所有,侵权请联系删除

当前修复情况

目前，Nginx 和 Apache HTTP Server 已经发布相关修复。

Nginx 用户建议升级到包含修复的版本，例如 1.29.8 或更新版本。部分环境中，如果此前已经升级到 1.30 以上版本，通常也会顺带规避该问题，但具体仍需要以实际安装来源、编译版本和发行版补丁状态为准。

Apache HTTP Server 用户建议升级到 2.4.68 或更新版本。Apache 官方确认，CVE-2026-49975 影响 Apache HTTP Server 2.4.17 到 2.4.67，并已在 2.4.68 中修复。

对于 Microsoft IIS、Envoy、Cloudflare Pingora 等组件，建议持续关注官方补丁进展。由于不同组件的修复节奏和漏洞编号可能并不完全一致，不建议只盯着 CVE-2026-49975 一个编号判断是否安全。

更稳妥的做法是：只要你的服务链路中有 HTTP/2，就应该检查对应组件是否已经发布修复、是否需要升级、是否需要临时关闭 HTTP/2。

图片来源于网络,版权归原作者所有,侵权请联系删除

临时缓解建议

如果暂时无法升级，可以根据业务情况采取以下措施：

1. 临时关闭 HTTP/2；
2. 在前置网关、WAF、负载均衡处限制请求头数量；
3. 限制异常连接数、请求速率和长时间占用连接；
4. 观察服务器内存、连接数、负载和网站访问状态；
5. 调整配置前，先做好网站和配置备份。

这里需要注意，关闭 HTTP/2 可能会影响部分站点性能体验，但相比服务被打到不可用，临时规避风险通常更重要。具体是否关闭，建议结合业务实际访问量、前置防护能力和升级条件来判断。

图片来源于网络,版权归原作者所有,侵权请联系删除

宝塔用户怎么处理？

如果使用 Nginx，建议检查当前 Nginx 版本，并尽快升级到包含修复（注意：1.29.8虽然规避了这个漏洞，但可能存在其他CVE漏洞，建议升级到1.30.1及以上版本）的版本。前段时间已经升级到 1.30 以上版本的用户，通常可以规避这类问题，但仍建议确认实际版本和运行状态。

重要提醒：切换版本会清空/www/server/nginx目录，如果你改过 Nginx 主配置文件，或者往这个目录放过什么东西，请务必记得备份！记得备份！记得备份！

图片来源于网络,版权归原作者所有,侵权请联系删除

如果暂时无法升级，可以先根据业务情况临时关闭 HTTP/2，并在 WAF、负载均衡、反向代理等前置节点上增加请求头数量、连接数和请求速率限制。

对于已经出现访问异常、内存快速上涨、服务频繁不可用的机器，也建议同步检查日志和监控，确认是否存在异常 HTTP/2 请求或持续占用连接的情况。

最近漏洞确实来得有点勤，让人看着有点累，但安全这件事不能靠"等等看"。该升级升级，该备份备份，该检查检查。处理完至少心里踏实一点。