写在前面
2026年6月，安全圈被一个编号为CVE-2026-49975的漏洞刷屏了。这个被称为“HTTP/2 Bomb”的远程拒绝服务漏洞，以一种近乎“降维打击”的方式，让全球超过88万个网站暴露在风险之中。
更令人震撼的是，这个漏洞竟是由 OpenAI 的 Codex AI 模型在分析公开代码库时发现的。一个在人类安全研究员眼皮底下存活了超过14年的协议设计缺陷，被 AI 一眼看穿。
本文将深入剖析 CVE-2026-49975 的技术原理，重点分析它对Microsoft IIS 服务器的威胁，并提供完整的检测、缓解与防御方案。
一、漏洞全景：HTTP/2 Bomb 到底是什么？
1.1 漏洞基本信息
根据美国国家漏洞数据库（NVD）和奇安信威胁情报中心的通报，CVE-2026-49975 的核心信息如下：
| 属性 | 内容 |
|---|---|
| 漏洞编号 | CVE-2026-49975 |
| 漏洞别名 | HTTP/2 Bomb |
| 公开时间 | 2026年6月2日 |
| CVSS 3.1 评分 | 9.8（高危）/ 7.5（高） |
| 威胁类型 | 拒绝服务（DoS） |
| 利用前提 | 无需身份验证，网络可达即可 |
| PoC 状态 | 已公开 |
| 在野利用 | 未发现（截至6月初） |
影响范围覆盖了几乎所有主流 Web 服务器：
- Microsoft IIS（含 Windows Server 2025）
- Nginx（< 1.29.8）
- Apache HTTPD（mod_http2 < 2.0.41，含 2.4.17 ~ 2.4.67）
- Envoy（≤ 1.37.2）
- Cloudflare Pingora（≤ 0.8.0）
1.2 攻击效果：一台普通电脑，20 秒拖垮服务器
根据 Imperva 和 HAProxy 官方的测试数据：
一个攻击者使用普通家用电脑，在 100 Mbps 的网络连接下，可在 10~20 秒内让目标服务器分配并锁定高达 32GB 的内存，导致服务器直接宕机。
更可怕的是，攻击者只需要建立单个 HTTP/2 连接，不需要大流量、不需要僵尸网络。这意味着传统基于流量阈值或连接数阈量的 DDoS 防护手段完全失效。
1.3 发现过程：AI 挖掘出 14 年“盲点”
这个漏洞的发现过程本身就是一个值得关注的故事。
根据 Calif 公司 CEO Thai Duong 的博客披露，Calif 团队使用 OpenAI 的 Codex AI 模型对多个公开代码库进行解析时，AI 识别出两个已知技术可以串联成一条完整的攻击链。
这两个技术分别是：
- HPACK 压缩炸弹（compression bomb）—— 已公开近十年
- Slowloris 风格的流量控制停滞（flow-control hold）—— 同样已知多年
人类安全研究员花了 14 年没能把这两者联系起来，AI 做到了。
这或许预示着安全行业的一个转折点：AI 辅助漏洞挖掘正在从“辅助工具”走向“核心发现引擎”。
二、技术深剖：HPACK 压缩 + 流量控制 = 完美风暴
要理解 CVE-2026-49975，必须深入理解 HTTP/2 的两个核心机制：HPACK 头压缩和流量控制（Flow Control）。
2.1 HPACK 头压缩：性能利器如何变成攻击武器
2.1.1 HPACK 工作原理简述
HTTP/2 于 2015 年由 IETF 正式发布。为了提升传输效率，HTTP/2 引入了HPACK头部压缩算法。
HPACK 的核心设计包含两个表：
- 静态表（Static Table）：包含 61 个常见的 HTTP 头部字段（如
:method: GET、:path: /等），所有连接共享，不可修改。 - 动态表（Dynamic Table）：在会话过程中动态更新，客户端和服务器各自维护一份。
通信双方通过索引（Index）来引用表中已有的头部字段，而不是每次都传输完整的字符串。例如，一个 1 字节的索引引用，可以代表一个完整的头部字段。
这本是为了节省带宽的设计，却成了漏洞的“放大器”。
2.1.2 压缩炸弹的攻击手法
根据 Calif 和 Imperva 的技术分析，攻击者的操作分为几步：
第一步：播种（Seeding）
攻击者发送一个几乎为空的头部 payload，但这个 payload 会被服务器放入 HPACK 动态表中。
第二步：索引引用轰炸（Indexed Reference Bombing）
攻击者随后发送成千上万个 1 字节的索引引用，每个引用都指向动态表中那个几乎为空的头部条目。
关键点在于：
- 每个 1 字节的引用，服务器都必须为其分配一个完整的内部数据结构（书签记录、内存表条目等）
- 由于头部本身很小，标准的“解码后头部大小限制”永远不会触发
- 内存放大倍数高达 5,700:1
“One byte on the wire becomes one full header allocation on the server, repeated thousands of times per request.”
—— Calif CEO Thai Duong
第三步：Cookie 拆分绕过限制（Apache/Envoy 特有）
对于实施了“最大头部数量”限制的服务器（如 Apache 的LimitRequestFields），攻击者还有一个变通手段：将 Cookie 头部拆分成无数个独立的 Cookie 字段。
Apache 和 Envoy 在合并 Cookie 字段时，未能正确计数，导致LimitRequestFields限制被绕过。
2.2 流量控制停滞：把内存“锁死”
如果说 HPACK 压缩炸弹是“打开水龙头”，那么流量控制停滞就是“堵住排水口”。
2.2.1 HTTP/2 流量控制机制
HTTP/2 的流量控制允许接收方通过WINDOW_UPDATE帧动态通告可用窗口大小。发送方只能在接收方通告的窗口范围内发送数据。
这本是为了防止接收方被数据淹没的保护机制。
2.2.2 攻击者的操作
根据多个安全厂商的分析，攻击者的操作是：
- 通告零字节的流量控制窗口（
WINDOW_UPDATEwith 0） - 服务器无法发送响应数据（因为窗口为 0）
- 连接一直处于“挂起”状态
- 攻击者每隔几秒发送 1 字节的 WINDOW_UPDATE 帧，重置发送超时计时器
- 服务器永远无法释放之前为 HPACK 条目分配的内存
这本质上是一种Slowloris 风格的攻击——用极低速率维持连接活跃，让服务器资源永远无法回收。
2.3 攻击链条完整示意
┌─────────────────────────────────────────────────────────────────────┐ │ CVE-2026-49975 攻击链条 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ ① 攻击者建立 HTTP/2 连接 │ │ ↓ │ │ ② 发送"几乎为空"的头部 → 服务器分配动态表条目（播种） │ │ ↓ │ │ ③ 发送数千个 1 字节索引引用 → 服务器分配数千个内部数据结构 │ │ （内存放大 5,700:1，但头部大小限制不触发） │ │ ↓ │ │ ④ 通告零字节流量控制窗口 → 服务器无法发送响应 │ │ ↓ │ │ ⑤ 定期发送 1 字节 WINDOW_UPDATE → 重置超时，保持连接活跃 │ │ ↓ │ │ ⑥ 内存被锁定 → 无法释放 → 服务器 OOM → 拒绝服务 │ │ │ │ 结果：20 秒内，单客户端耗尽 32GB 服务器内存 │ └─────────────────────────────────────────────────────────────────────┘三、IIS 服务器：处境最危险的玩家
3.1 IIS 的尴尬位置
在所有受影响的主流 Web 服务器中，Microsoft IIS 的处境最为尴尬：
| 服务器 | 修复状态 | 修复版本 |
|---|---|---|
| Nginx | ✅ 已修复 | 1.29.8+（2025年4月） |
| Apache HTTPD | ✅ 已修复 | mod_http2 2.0.41+（2026年5月） |
| Microsoft IIS | ❌ 未修复 | 暂无补丁 |
| Envoy | ❌ 未修复 | 暂无补丁 |
| Cloudflare Pingora | ❌ 未修复 | 暂无补丁 |
根据 cybersecurity-help.cz 的漏洞数据库，截至 2026 年 6 月 8 日，官方尚无针对 IIS 的解决方案。
根据 Red Hat 的安全公告，Apache 的 CVE-2026-49975 已被评定为Important级别。而 IIS 的官方补丁状态仍是“未知”。
3.2 IIS 为何“中招”
根据漏洞描述，IIS 的漏洞存在于HTTP/2 请求处理和 HPACK 头部处理过程中，当处理以下两种恶意请求时触发：
- 重复的索引头部引用（repeated indexed header references）
- 停滞的流量控制窗口（stalled flow-control window）
关键在于：该问题在默认 HTTP/2 配置下即可被利用。也就是说，只要 IIS 开启了 HTTP/2（默认开启），就存在风险。
3.3 Windows Server 2025 也未能幸免
根据多个安全公告的确认，Windows Server 2025 自带的 IIS 同样受影响。这意味着：
- 即便是微软最新版本的服务器操作系统
- 即便是默认配置、未做任何修改的 IIS
- 同样可以被 HTTP/2 Bomb 一击击倒
四、实战检测：如何判断你的 IIS 是否中招
4.1 自查清单
在等待微软官方补丁的同时，建议按照以下清单进行自查：
| 检查项 | 操作 | 预期结果 |
|---|---|---|
| HTTP/2 是否启用 | 检查 IIS 站点绑定是否包含https且未禁用 HTTP/2 | 如启用则存在风险 |
| 内存使用趋势 | 监控w3wp.exe进程内存 | 如出现异常陡增则可能被攻击 |
| 连接状态 | 检查是否有大量长连接处于CLOSE_WAIT或挂起状态 | 异常则需警惕 |
| 日志分析 | 检查 HTTP/2 相关错误日志 | 查找异常请求模式 |
4.2 监控脚本示例
以下 PowerShell 脚本可用于监控 IIS 工作进程的内存使用情况：
# IIS 内存监控脚本# 建议每 5 分钟执行一次，记录到日志$ThresholdMB= 2048# 设置告警阈值（2GB）$ProcessName="w3wp"$Processes=Get-Process-Name$ProcessName-ErrorAction SilentlyContinueforeach($Procin$Processes){$MemoryMB=[math]::Round($Proc.WorkingSet/1MB,2)$TimeStamp=Get-Date-Format"yyyy-MM-dd HH:mm:ss"if($MemoryMB-gt$ThresholdMB){Write-Warning"[$TimeStamp] WARNING:$($Proc.ProcessName)(PID:$($Proc.Id)) memory: ${MemoryMB}MB"# 可在此触发告警通知}else{Write-Host"[$TimeStamp] INFO:$($Proc.ProcessName)(PID:$($Proc.Id)) memory: ${MemoryMB}MB"}}4.3 流量特征识别
根据 Imperva 威胁研究团队的观察，攻击初期的流量特征包括：
- 密集的小型头部块突发（aggressive, dense bursts of small header blocks）
- 受限窗口下的持续连接（connections under restricted windows without terminating）
- 自动化的探测行为（automated probing behavior），而非标准的应用层 payload
这些特征可以帮助安全团队在 WAF 或网络层进行早期识别。
五、缓解方案：微软补丁出来前我们能做什么？
5.1 方案对比总览
| 方案 | 适用场景 | 有效性 | 副作用 | 实施难度 |
|---|---|---|---|---|
| 禁用 HTTP/2 | 所有 IIS 部署 | ⭐⭐⭐⭐⭐ | 性能下降 | 低 |
| 前置反向代理 | 有 HAProxy/Nginx 的环境 | ⭐⭐⭐⭐⭐ | 架构调整 | 中 |
| 内存限制（cgroups） | 容器化部署 | ⭐⭐⭐ | 可能 OOM-kill | 中 |
| WAF 规则 | 有 WAF 的环境 | ⭐⭐⭐⭐ | 需更新规则 | 低 |
5.2 方案一：禁用 HTTP/2（最直接）
根据 Red Hat 的安全公告，禁用 HTTP/2 是最直接有效的缓解措施。
IIS 中禁用 HTTP/2 的方法：
- 打开IIS 管理器
- 选择目标站点，双击“绑定”
- 编辑 HTTPS 绑定
- 在“SSL 设置”中，取消勾选“启用 HTTP/2”
或者通过 PowerShell：
# 禁用特定站点的 HTTP/2# 注意：需要 IIS 10.0 及以上版本Import-ModuleWebAdministration# 查看当前 HTTP/2 状态Get-WebConfigurationProperty-Filter"system.webServer/httpProtocol"-Name"allowHttp2"-Location"Default Web Site"# 禁用 HTTP/2Set-WebConfigurationProperty-Filter"system.webServer/httpProtocol"-Name"allowHttp2"-Value$false-Location"Default Web Site"# 重启 IISiisreset⚠️ 禁用 HTTP/2 的影响：
根据 Red Hat 的官方说明：
- ✅兼容性不受影响——所有现代浏览器和 API 客户端会自动回退到 HTTP/1.1
- ⚠️页面加载速度下降——HTTP/1.1 顺序传输文件，无法利用 HTTP/2 的多路复用
- ⚠️带宽消耗增加——HTTP/1.1 传输未压缩的纯文本头部，失去 HPACK 的数据节省
- ⚠️TCP 连接数、CPU 和内存使用会上升
建议：如果业务对性能要求极高，可以考虑仅在非关键业务时段禁用，或采用方案二。
5.3 方案二：前置反向代理（“虚拟补丁”）
HAProxy 官方明确表示：如果在 Web 服务器前部署 HAProxy，则已受到保护。
HAProxy 之所以免疫，是因为它作为协议终结者（protocol terminator），在边缘网络安全地处理客户端 HTTP/2 流量，并以 HTTP/1.1 转发给后端服务器。后端 IIS 服务器根本不直接面对恶意 HTTP/2 请求。
HAProxy 配置示例：
# haproxy.cfg - 前置 HAProxy 保护 IIS 后端 frontend http2_frontend bind :443 ssl crt /etc/ssl/certs/server.pem alpn h2,http/1.1 mode http # 限制请求头数量 - 针对 CVE-2026-49975 http-request deny if { hdr_cnt(cookie) gt 100 } # 限制单个连接上的流数量 http-request deny if { sc_http2_streams gt 100 } default_backend iis_backend backend iis_backend mode http server iis1 192.168.1.10:80 check # 以 HTTP/1.1 转发，IIS 不直接面对 HTTP/2 攻击5.4 方案三：Nginx 作为 TLS 终结代理
如果你的环境已经使用 Nginx 作为反向代理，那么好消息是：Nginx 1.29.8+ 已经修复了此漏洞。
Nginx 1.29.8 引入了max_headers指令，默认限制为 1000 个请求头。
# nginx.conf - 作为 IIS 的前置代理 http { # 限制请求头数量 - CVE-2026-49975 缓解 max_headers 1000; # 默认值，可显式配置 # 限制头部大小 large_client_header_buffers 4 16k; server { listen 443 ssl http2; server_name your-domain.com; # 代理到后端 IIS location / { proxy_pass http://iis-backend:80; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 禁用后端 HTTP/2，使用 HTTP/1.1 proxy_http_version 1.1; } } }5.5 方案四：内存限制（终极防线）
如果无法禁用 HTTP/2 也无法前置代理，可以考虑为 IIS 工作进程设置严格的内存限制。
在 Windows 环境中，可以通过以下方式：
方法一：IIS 应用程序池内存限制
- 打开 IIS 管理器
- 选择“应用程序池”
- 右键目标池 →“高级设置”
- 在“回收”部分：
- 设置“虚拟内存限制”（如 2GB）
- 设置“专用内存限制”（如 2GB）
方法二：Job Object 限制（更精细）
# 使用 PowerShell 为进程设置内存限制# 需要管理员权限$ProcessName="w3wp"$MemoryLimitMB= 2048# 获取所有 w3wp 进程$Procs=Get-Process-Name$ProcessNameforeach($Procin$Procs){# 使用 Set-Process 设置内存限制（需要 Windows 10/Server 2016+）# 注意：此操作需要安装相应的 PowerShell 模块try{Set-Process-Id$Proc.Id-MemoryLimit$MemoryLimitMB-ErrorAction StopWrite-Host"Set memory limit for PID$($Proc.Id)to ${MemoryLimitMB}MB"}catch{Write-Warning"Failed to set memory limit for PID$($Proc.Id):$_"}}⚠️注意：内存限制可能导致工作进程被 OOM-kill，需确保 IIS 的快速故障保护和进程回收机制已启用，以便被 kill 的进程能自动重启。
六、补丁追踪：什么时候能等来微软的官方修复？
6.1 各厂商修复时间线
| 时间 | 事件 |
|---|---|
| 2025年4月 | Nginx 1.29.8 悄然发布，引入max_headers指令 |
| 2026年5月下旬 | Apache 在 mod_http2 v2.0.41 中修复 |
| 2026年6月2日 | CVE-2026-49975 公开披露 |
| 2026年6月3日 | Calif 发布完整技术文档 |
| 2026年6月4日 | 各安全厂商发布公告，PoC 公开 |
| 待定 | Microsoft IIS 官方补丁 |
6.2 关注渠道
建议通过以下渠道追踪微软的补丁进展：
- Microsoft Security Response Center（MSRC）：官方安全公告
- Microsoft Update Catalog：补丁发布
- Windows Server 更新服务（WSUS）：企业环境
- Microsoft TechCommunity IIS 板块
6.3 3CX 的应急响应案例
3CX 的应对策略值得参考：
漏洞披露后，3CX 发现Debian Bookworm 和 Trixie 仓库中尚无打过补丁的 Nginx 版本。他们没有等待 Debian 维护者，而是直接将 Nginx 嵌入到 3CX 的安装和更新流程中，绕过操作系统包管理依赖，在 48 小时内向客户推送了热修复。
启示：对于关键业务系统，不应完全依赖操作系统发行版的补丁周期。建立自己的应急响应和热修复能力至关重要。
七、深度思考：为什么 HTTP/2 的设计缺陷能存活 14 年？
7.1 协议设计的“合理误用”困境
CVE-2026-49975 之所以能存活如此之久，根本原因在于：攻击者利用的每一个步骤，单独来看都是符合 HTTP/2 协议规范的合法行为。
- HPACK 索引引用是协议的标准功能
- 流量控制窗口通告是协议的标准功能
- 保持连接活跃也是协议的标准行为
没有任何一个单独的操作是“违规”的。攻击链的威力来自这些合法操作的组合。
这揭示了一个深刻的教训：协议安全不能只审查单个功能是否合规，还必须审查功能的组合效应。
7.2 AI 漏洞挖掘的启示
根据 CSO Online 的报道，这个漏洞在14 年间经历了无数人类安全研究员的审查，却始终未被发现。
直到 Calif 使用OpenAI Codex进行辅助分析：
AI 模型解析了多个公开代码库，识别出两个各自公开了近十年的技术可以被无缝串联成一条攻击链。
这标志着安全行业的一个重要转折点：
| 维度 | 传统人工审计 | AI 辅助审计 |
|---|---|---|
| 代码覆盖率 | 有限 | 大规模并行 |
| 跨项目关联 | 依赖专家经验 | 自动模式识别 |
| 发现速度 | 数月到数年 | 数小时到数天 |
| 组合攻击识别 | 困难 | 相对容易 |
7.3 HTTP/3 能幸免吗？
HTTP/3 基于 QUIC 协议，使用QPACK代替 HPACK 进行头部压缩。
QPACK 在设计上确实修复了 HPACK 的一些已知问题，但是否能完全避免此类组合攻击尚待时间检验。
短期内不建议将“升级到 HTTP/3”作为 CVE-2026-49975 的解决方案——因为：
- HTTP/3 的部署率远低于 HTTP/2
- QPACK 本身也可能存在尚未发现的组合漏洞
- 大多数现有基础设施尚未支持 HTTP/3
八、实践建议与趋势判断
8.1 立即行动清单（优先级排序）
| 优先级 | 行动项 | 负责团队 |
|---|---|---|
| 🔴P0 | 确认所有面向公网的 IIS 服务器是否开启了 HTTP/2 | 运维/安全 |
| 🔴P0 | 对无法立即修补的服务器，禁用 HTTP/2或前置代理 | 运维 |
| 🟡P1 | 部署内存监控，设置告警阈值 | 运维 |
| 🟡P1 | 更新 WAF/IPS 规则（Check Point、Imperva 等已发布规则） | 安全 |
| 🟢P2 | 关注微软官方补丁，制定灰度发布计划 | 运维/安全 |
| 🟢P2 | 评估业务对 HTTP/2 的依赖程度，制定长期协议策略 | 架构 |
8.2 长期架构建议
分层防御：不要将 Web 服务器直接暴露在公网。在前端部署反向代理（HAProxy/Nginx/Envoy）作为 TLS 终结层，后端服务器仅接受 HTTP/1.1 流量。
默认安全：审查所有默认启用的协议功能。“默认开启”不等于“默认安全”。
资源隔离：为 Web 服务器工作进程设置严格的内存和连接数限制，即使漏洞被利用，也能将影响控制在单个进程范围内。
AI 辅助安全审计：将 AI 代码分析工具纳入安全开发生命周期（SDL），尤其是在协议实现和复杂状态机的审计中。
8.3 趋势判断
第一，HTTP/2 协议层的漏洞不会到此为止。HPACK 和流量控制的组合攻击只是揭开了冰山一角。随着 AI 辅助漏洞挖掘的普及，更多类似的“组合型”协议漏洞将被发现。
第二，“虚拟补丁”将成为新常态。对于 IIS、Envoy 等补丁滞后的平台，前置 WAF/反向代理将成为事实上的标准防御手段。
第三，AI 在安全领域的角色正在从“辅助”转向“主导”。CVE-2026-49975 的发现过程证明，AI 在识别跨组件、跨项目的组合攻击方面具有人类难以企及的优势。
写在最后
CVE-2026-49975 不仅是一个技术漏洞，更是一面镜子。
它照出了HTTP/2 协议设计中“合法功能组合”带来的安全隐患，照出了传统人工安全审计的局限性，也照出了AI 在安全领域的巨大潜力。
对于 IIS 管理员来说，现在能做的就是立刻行动——要么禁用 HTTP/2，要么前置代理，要么做好内存监控。等待微软补丁是被动的，主动防御才是安全的。
对于整个行业来说，CVE-2026-49975 或许只是一个开始。在 AI 辅助漏洞挖掘的时代，我们可能需要重新审视许多“已知安全”的协议和系统。
安全没有终点，只有不断演进的攻防博弈。
参考资料：
- Calif 官方博客：
blog.calif.io/p/codex-discovered-a-hidden-http2-bomb - Imperva 安全公告（2026年6月4日）
- HAProxy 官方博客（2026年6月5日）
- Red Hat 安全公告 RHSB-2026-007
- 奇安信威胁情报中心安全通告（2026年6月4日）
- NVD：
nvd.nist.gov/vuln/detail/CVE-2026-49975
