写在前面

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 识别出两个已知技术可以串联成一条完整的攻击链。

这两个技术分别是：

1. HPACK 压缩炸弹（compression bomb）—— 已公开近十年
2. 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 攻击者的操作

根据多个安全厂商的分析，攻击者的操作是：

1. 通告零字节的流量控制窗口（WINDOW_UPDATE with 0）
2. 服务器无法发送响应数据（因为窗口为 0）
3. 连接一直处于“挂起”状态
4. 攻击者每隔几秒发送 1 字节的 WINDOW_UPDATE 帧，重置发送超时计时器
5. 服务器永远无法释放之前为 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 头部处理 过程中，当处理以下两种恶意请求时触发：

1. 重复的索引头部引用（repeated indexed header references）
2. 停滞的流量控制窗口（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 SilentlyContinue

foreach ($Proc in $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 的方法：

1. 打开 IIS 管理器
2. 选择目标站点，双击 “绑定”
3. 编辑 HTTPS 绑定
4. 在 “SSL 设置” 中，取消勾选 “启用 HTTP/2”

或者通过 PowerShell：

# 禁用特定站点的 HTTP/2
# 注意：需要 IIS 10.0 及以上版本

Import-Module WebAdministration

# 查看当前 HTTP/2 状态
Get-WebConfigurationProperty -Filter "system.webServer/httpProtocol" -Name "allowHttp2" -Location "Default Web Site"

# 禁用 HTTP/2
Set-WebConfigurationProperty -Filter "system.webServer/httpProtocol" -Name "allowHttp2" -Value $false -Location "Default Web Site"

# 重启 IIS
iisreset

⚠️ 禁用 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 应用程序池内存限制

1. 打开 IIS 管理器
2. 选择 “应用程序池”
3. 右键目标池 → “高级设置”
4. 在 “回收” 部分：
   • 设置 “虚拟内存限制”（如 2GB）
   • 设置 “专用内存限制”（如 2GB）

方法二：Job Object 限制（更精细）

# 使用 PowerShell 为进程设置内存限制
# 需要管理员权限

$ProcessName = "w3wp"
$MemoryLimitMB = 2048

# 获取所有 w3wp 进程
$Procs = Get-Process -Name $ProcessName

foreach ($Proc in $Procs) {
    # 使用 Set-Process 设置内存限制（需要 Windows 10/Server 2016+）
    # 注意：此操作需要安装相应的 PowerShell 模块
    try {
        Set-Process -Id $Proc.Id -MemoryLimit $MemoryLimitMB -ErrorAction Stop
        Write-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 关注渠道

建议通过以下渠道追踪微软的补丁进展：

1. Microsoft Security Response Center（MSRC） ：官方安全公告
2. Microsoft Update Catalog：补丁发布
3. Windows Server 更新服务（WSUS） ：企业环境
4. 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 的解决方案——因为：

1. HTTP/3 的部署率远低于 HTTP/2
2. QPACK 本身也可能存在尚未发现的组合漏洞
3. 大多数现有基础设施尚未支持 HTTP/3

八、实践建议与趋势判断

8.1 立即行动清单（优先级排序）

优先级	行动项	负责团队
🔴 P0	确认所有面向公网的 IIS 服务器是否开启了 HTTP/2	运维/安全
🔴 P0	对无法立即修补的服务器，禁用 HTTP/2 或前置代理	运维
🟡 P1	部署内存监控，设置告警阈值	运维
🟡 P1	更新 WAF/IPS 规则（Check Point、Imperva 等已发布规则）	安全
🟢 P2	关注微软官方补丁，制定灰度发布计划	运维/安全
🟢 P2	评估业务对 HTTP/2 的依赖程度，制定长期协议策略	架构

8.2 长期架构建议

1. 分层防御：不要将 Web 服务器直接暴露在公网。在前端部署反向代理（HAProxy/Nginx/Envoy）作为 TLS 终结层，后端服务器仅接受 HTTP/1.1 流量。

2. 默认安全：审查所有默认启用的协议功能。“默认开启”不等于“默认安全” 。

3. 资源隔离：为 Web 服务器工作进程设置严格的内存和连接数限制，即使漏洞被利用，也能将影响控制在单个进程范围内。

4. 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