HTTP/2 Bomb 漏洞怎么处理？CVE-2026-49975 的影响范围与缓解思路

Thu, 11 Jun 2026 08:43:45 +0800

HTTP/2 Bomb 是近期公开的一个 HTTP/2 拒绝服务风险。它和 CVE-2026-49975 相关，核心问题是攻击者可以用很小的请求，让服务端分配并长时间占用大量内存，最终导致服务变慢、进入 swap，甚至不可用。

这个问题最容易被误解成“又一个普通 DDoS”。但它的危险点不在于流量大，而在于内存放大明显：客户端发出的数据很少，服务端却可能在处理 HTTP/2 头部压缩和流控状态时承担成倍资源消耗。

对运维和安全团队来说，当前最重要的不是复现攻击，而是先确认自己哪里终止了 HTTP/2，再按组件升级或临时关闭 HTTP/2。

这个漏洞危险在哪里

HTTP/2 Bomb 把两类老问题组合在了一起。

第一类是 HPACK 相关的压缩放大。HTTP/2 使用 HPACK 压缩头部，客户端可以用很短的引用让服务端还原和分配头部结构。如果实现没有对头字段数量、Cookie 分片或内部簿记开销做足够限制，服务端就可能为很小的输入分配大量内存。

第二类是类似 Slowloris 的“拖住不放”。攻击端可以利用 HTTP/2 的流控机制，让服务端响应无法正常完成，从而把前面分配出来的内存长时间钉在进程里。

单独看，这两类问题都不新。真正麻烦的是它们叠加以后，攻击不需要很高带宽，也不一定需要海量连接，就可能把后端内存压到危险状态。

哪些组件需要重点关注

公开披露中提到的受影响或需要关注的 HTTP/2 服务端实现包括：

nginx
Apache httpd
Microsoft IIS
Envoy
Cloudflare Pingora

NVD 当前对 CVE-2026-49975 的描述聚焦在 Apache HTTP Server mod_http2，影响范围为 Apache HTTP Server 2.4.17 到 2.4.67。Red Hat 公告也把相关问题归到 HTTP/2 HPACK 拒绝服务，并指出 httpd、nginx、Envoy 等组件需要分别处理。

这里要注意两个细节。

第一，不是所有“后端应用服务”都直接暴露这个风险。真正需要先排查的是 HTTP/2 终止点：公网负载均衡、反向代理、Ingress、网关、CDN 回源层、API Gateway、服务网格入口等。

第二，不同厂商、发行版和产品的 CVE 归属不完全一致。不要只看一个 CVE 编号就判断所有组件都已覆盖；更稳妥的做法是按实际 HTTP/2 组件查看对应厂商公告。

怎么快速自查

可以先按这条顺序排查：

你的公网入口是否启用了 HTTP/2；
HTTP/2 在哪里终止，是 CDN、WAF、负载均衡、Nginx、Apache、Envoy、IIS，还是服务网格；
终止 HTTP/2 的组件版本是否在厂商已修复范围内；
是否有上游代理能限制请求头字段数量、Cookie 分片、连接生命周期和单 worker 内存；
是否存在绕过 CDN/WAF 直连源站的入口。

很多网站看似有 CDN，但源站 IP、备用域名、测试域名、管理入口或灰度入口仍然可能直接暴露 HTTP/2。真正要检查的是“所有能接 HTTP/2 的边界”，不只是主站域名。

修复和缓解建议

优先级最高的是升级。

如果使用 nginx，公开披露中提到 1.29.8+ 引入了相关限制。无法升级时，可以考虑临时关闭 HTTP/2。

如果使用 Apache httpd，需要关注 mod_http2 修复版本。公开资料提到 mod_http2 v2.0.41 进行了修复；Red Hat 给出的临时缓解方式是让相关虚拟主机只使用 HTTP/1.1：

`1`	`Protocols http/1.1`

如果使用 nginx 并需要临时缓解，可以按厂商或发行版建议关闭 HTTP/2，例如：

`1`	`http2 off;`

如果使用 Envoy、IIS、Pingora 或托管网关，要跟随对应厂商公告。不要直接套用 Nginx 或 Apache 的配置思路，因为具体限制点和修复方式可能不同。

对于暂时无法升级的系统，可以考虑这些防守措施：

在边界层限制单请求头字段数量，包括拆分后的 cookie 字段；
限制异常长生命周期的 HTTP/2 stream；
对 HTTP/2 入口设置连接数、并发 stream、请求速率和内存上限；
对 worker 或容器设置合理内存上限，避免一个进程拖垮整机；
让源站只接受可信代理访问，避免绕过 WAF/CDN；
监控 HTTP/2 连接数、活跃 stream、内存飙升、swap 使用和 5xx。

这些措施不能替代补丁，但能减少暴露窗口。

哪些场景风险更高

风险更高的通常是这些环境：

公网直接暴露 HTTP/2 的 Nginx / Apache / Envoy / IIS；
API 网关或 Ingress 接入层开启 HTTP/2；
源站可以被绕过 CDN 直接访问；
单机内存较小，但承载多个站点或多个业务；
没有 worker / container 内存限制；
缺少异常连接、stream 和内存监控；
业务对可用性敏感，但没有快速回滚 HTTP/1.1 的预案。

如果你的服务只在内网使用，也不能完全忽略。内网攻击、误用测试脚本、供应链组件暴露、服务网格入口配置错误，都可能让风险从公网问题变成横向移动后的可用性问题。

不要只盯 CVSS 分数

这类漏洞的分数容易让人困惑。有的资料强调 CVSS 9.8，NVD 页面当前又显示 CISA-ADP 给出的 CVSS 3.1 为 7.5 High，且 NVD 自身评分仍在补充中。

对实际防守来说，分数不是第一判断依据。更实用的问题是：

你的 HTTP/2 入口是否受影响；
是否公网可达；
是否已经升级到厂商修复版本；
是否能快速关闭 HTTP/2；
是否有内存、连接和 stream 级别的保护；
是否存在绕过前置防护直连源站的路径。

如果这些问题里有多个答案不确定，就应该按高优先级处理。

运维侧建议的处理顺序

可以按下面的顺序推进：

列出所有 HTTP/2 终止点；
对照厂商公告确认版本和修复状态；
优先升级公网入口和边界代理；
对暂时无法升级的入口临时关闭 HTTP/2；
检查源站是否只允许可信代理访问；
给 worker、容器或服务进程设置内存边界；
加上 HTTP/2 连接、stream、请求头字段数量和内存异常监控；
在变更窗口后验证业务是否仍能正常访问。

关闭 HTTP/2 可能影响性能、连接复用和部分客户端体验，但在补丁不可用或风险不清楚时，这是比裸奔更稳的临时选择。

结论

HTTP/2 Bomb 的关键不是“流量有多大”，而是“小请求触发大内存占用，并且能把内存占用拖住”。这让它对默认开启 HTTP/2 的边界服务更危险。

处理时不要急着复现，也不要只看某个 CVE 页面。先找出所有 HTTP/2 终止点，再按 Nginx、Apache、Envoy、IIS、Pingora 或发行版公告逐个确认。能升级就升级，不能升级就临时关闭 HTTP/2，并在边界层增加头字段、连接、stream 和内存限制。

参考来源：Calif 原始披露、NVD CVE-2026-49975、HAProxy 分析、Red Hat RHSB-2026-007

Apache on KnightLi的博客